Re: : Previous Node information in MPLS enabled node (LSR)
Truman Boyes <truman <at> suspicious.org>
2007-04-11 22:20:43 GMT
Hi Shashwat,
Yes I see your point. I agree there are some backbone networks that
will have nodes that will act as LSR for some FECs and Ingress or
Egress for other FECs. Perfectly natural.
However, what could be brought into question is the viability or
desirability of having IP lookups performed on all LSRs. This
essentially means that the entire routing information within the
domain must be present on all nodes.
In production networks today, there is a shift or trend to distribute
function. Most MPLS networks are starting to have LSR-only nodes (P
nodes) and ingress / egress nodes (PE). Although it is possible to
create static LSPs, the routing information that is present within
all nodes is the ability to reach *each other*. External routing
information (ie. the kind of info that we would need to handle the IP
packet that reaches an arbitrary node in the network), would need be
present so that forwarding for that packet could be achieved.
I have designed networks that consist of ingress/ egress nodes and
LSR nodes. The LSR nodes have very sparse routing information. In
fact, the only IP packets that the LSR sees are routing protocol
traffic. These nodes will never see transit IPv4/IPv6. In smaller
networks, this approach may not be feasible, as cost may dictate the
need for dual purpose nodes.
But going back to the scenario that you described. Let's say that ip
source "A" is attempting to reach ip source "B". Source "A" sends an
IP packet to LSR-1. LSR-1 performs a lookup on the IP destination. If
we don't have a route, we drop the packet and we send an ICMP error
message back to source "A". If we have an MPLS destination in the
routing table based on the IP destination, we will forward the packet
encapsulated in MPLS towards the next-hop. If we had an IP
destination for the packet, we would forward the packet in plain IP
to the next-hop in our table.
As you mentioned, there could be a case where we have a valid IP
route for the packet but when an LSP is established, the MPLS path
would be preferred. This all would come down to protocol preferences,
but on most implementations LDP and RSVP and Static mappings of
labels are preferred over EGP and IGP protocols. The FTN mapping on
the second node assumes that there is a full routing view on all
nodes ...
Is the reason for avoid multiple FTN generation to prevent
inefficiencies in forwarding? I am trying to understand the why's?
Truman
On 12/04/2007, at 1:44 AM, Shashwat Srivastava wrote:
> Hi Truman,
>
> I agree with your points except the last paragraph. I feel I need to
> elaborate more here:
> ---
> You wrote...
> A question that popped up in my mind, regarding the scenario you
> described, if about why should subsequent LSR's in the network create
> generate FTN for the IP packet? Wouldn't denying this ability
> actually reduce negative effects of multiple FTN generations?
> ---
>
> I shall tell you our approach. This is quite correct, as any node
> in an MPLS
> backbone can behave as an LSR for some FEC and as an Ingress or
> Egress for
> some other FECs. Think a real life scenario instead of considering
> any node
> to be an LSR only (of course for some particular FEC). So the
> possibility of
> multiple FTN request generation can not be denied. The MPLS enabled
> node is
> an Ingress for some FEC only if the incoming IP packet is coming
> from a node
> of different GROUP than the Ingress node in consideration.
>
> I hope you get my point now. Any idea as to how these things are
> dealt with
> in a real life IP-MPLS interconnection.
>
> Thanks and Regards,
> Shashwat Srivastava
>
>
> -----Original Message-----
> From: Truman Boyes [mailto:truman <at> suspicious.org]
> Sent: Wednesday, April 11, 2007 5:58 PM
> To: Shashwat Srivastava
> Cc: mpls-ops <at> mplsrc.com; shashwat_iitg <at> yahoo.com
> Subject: Re: [MPLS-OPS]: Previous Node information in MPLS enabled
> node
> (LSR)
>
> Hi Shashwat,
>
> An EtherType approach assumes that you will be sending Ethernet on
> all links. In point-to-point links, the technology will probably be
> SONET/SDH with MPLS framing over PPP/HDLC. There would be local
> information in the previous hop that would "know" that the packet
> came from a particular "GROUP".
>
> The concept that you driving towards is a way of creating an
> abstraction layer that allows you to "GROUP" nodes, and then
> propagate information regarding these nodes. This abstraction seems a
> lot better suited in a protocol that understands boundaries. (ie.
> BGP). You could then design rules that would enforce forwarding
> decisions based on propagated information.
>
> A question that popped up in my mind, regarding the scenario you
> described, if about why should subsequent LSR's in the network create
> generate FTN for the IP packet? Wouldn't denying this ability
> actually reduce negative effects of multiple FTN generations?
>
> kind regards,
> Truman
>
>
>
>
> On 11/04/2007, at 10:32 PM, Shashwat Srivastava wrote:
>
>> Hi Truman,
>> Thanks for the response. Please find my comments inline.
>>
>> -----Original Message-----
>> From: Truman Boyes [mailto:truman <at> suspicious.org]
>> Sent: Wednesday, April 11, 2007 3:04 PM
>> To: Shashwat Srivastava
>> Cc: mpls-ops <at> mplsrc.com; shashwat_iitg <at> yahoo.com
>> Subject: Re: [MPLS-OPS]: Previous Node information in MPLS enabled
>> node
>> (LSR)
>>
>> Hi Shashwat,
>>
>> Let me see if I understand what you are discussing; you are talking
>> about the possibility that you will have a network that contains some
>> MPLS enabled nodes, and some IP nodes. Some functionality will
>> overlap between nodes.
>>
>> You then go on to discuss the possibility that a packet that is
>> carried by an MPLS network may reach a LSR, and the destination is
>> not reachable via MPLS, but rather via a IPv4 nexthop. In this case
>> you will then pop the MPLS shim and perform standard routing.
>>
>> Now, my question is regarding the issue that you are solving or
>> simulating. In MPLS-enabled backbones there are many cases where
>> there is overlap between functionality. More specifically, most LER/
>> LSR nodes are IP routers first, and the MPLS functionality has been
>> added over time. Is your approach unique in that decisions on the
>> proper network to forward to is based on the LLC type?
>>
>>
>>>> The EtherType approach is fine and a node always sends a packet to
>>>> MAC after deciding beforehand about the target layer (MPLS OR
>>>> IPv4 OR IPv6
>>>> etc.). This is not the bottleneck in my task.
>>>>
>>
>> If this is the case, I would point out a few considerations:
>>
>> Interfaces on LER's will have a configured protocol family on which
>> they will receive traffic. For example, in most service provider's
>> networks, they will have MPLS run inside their network, but they will
>> not accept MPLS packets from customers. More to the point, they don't
>> run RSVP or LDP with customers. Well some might, but these are
>> special cases that I would think are unique.
>>>> That's good point, here we are not targeting to deal with
>>>> filtering out
>>>> Packets based on the source IP (e.g. IP addresses of customers as
>>>> you
>>>> mentioned) or any other such criteria.
>>>>
>>>> I am wondering the benefit of knowing if the previous node was MPLS
>>>> enabled or not MPLS enabled.
>>>>
>>>> I want to elaborate this point more...
>>>> I want to define a term GROUP: A GROUP consists of all the nodes
>>>> which are
>>>> In the same subnet and are all of same type (ALL MPLS or ALL Pure-
>>>> IP).
>>>>
>>>> The need is not of knowing whether the previous node was MPLS
>>>> enabled OR
>>>> It was a Pure-IP node, but whether the previous node was in the
>>>> same MPLS
>>>> backbone(more precisely in the same GROUP).
>>>> The need of knowing this can be understood by the following
>>>> scenarios:
>>>> i.) An IP packet arrives at some node of the MPLS backbone
>>>> (Ingress). This
>>>> node generates a FTN request and until the LSP is established, all
>>>> subsequent incoming packets at this Ingress will be forwarded to
>>>> IP by
>>>> Ingress. Since the next hop, as determined by IP, may be another
>>>> MPLS node
>>>> of the same GROUP, to which Ingress belongs to, there will be
>>>> another FTN
>>>> request generated at that node. This is the case of multiple FTN
>>>> generation.
>>>>
>>>> ii.) The second case may be, suppose the MTU of outgoing
>>>> interface may be
>>>> lesser for some incoming MPLS packet at an Intermediate LSR. This
>>>> LSR will
>>>> decide not to drop the packet, but instead pop the Label and
>>>> forward such
>>>> decapsulated IP packet to IP. Now this packet can again, as in
>>>> case (i.)
>>>> come to any other node (the next hop) in the same GROUP and will
>>>> try to
>>>> trigger the FTN map request. This must be avoided.
>>>>
>>>> For case i.) and ii.) to work well, we can have a check at every
>>>> node
>>>> that:
>>>> IF the previous node was in the same GROUP or NOT. This will
>>>> suffies the
>>>> decision making at Ingress and LSRs, whether to forward the
>>>> packet to MPLS
>>>> or let it get forwarded via IP.
>>>> Even a node understands that it is an >>Egress only based on the
>>>> GROUP
>>>> information, that whether the next node is in the same GRUP or NOT?
>>>> ..Please refer: section 2.6.1.2. of rfc 3036 which states:
>>>> -------
>>>> An LSR may act as an egress LSR, with respect to a particular FEC,
>>>> under any of the following conditions:
>>>>
>>>>
>>>> 1. The FEC refers to the LSR itself (including one of its
>>>> directly
>>>> attached interfaces).
>>>>
>>>> 2. The next hop router for the FEC is outside of the Label
>>>> Switching Network.
>>>> -----
>>>>
>>>> Point 2 can only be realized if we have GROUP information
>>>> available. So at
>>>> Egress you must know that the next hop is not in the same GROUP,
>>>> to which
>>>> Egress belongs to, and hence it is the Egress for this FEC.
>>>>
>>
>> In MPLS switching or even IP routing,
>> the information relating to the destination is the most relevant. For
>> example, lets say that LSR "A" receives a MPLS packet with label
>> information that it has no knowledge of, in most common
>> implementations, the packet would be dropped. If you are saying to
>> pop shim and then route the packet, well then we would be assuming
>> that the data inside the MPLS packet is an IPv4 packet that the
>> router could process. The MPLS packet may contain information that
>> can not be handled or forwarded by the LSR; for example in the case
>> of a L2VPN or a three label stack for carrier of carrier VPNs.
>>>> We are not considering Tunnel cases, so I am not considering this
>> scenario. We are only considering single Label MPLS stack presently.
>>
>> If router "A" receives an IPv4 packet on an interface that accepts
>> IPv4, it may perform a lookup on the destination address, and
>> discover that the best way to forward the packet is to a destination
>> route that is learned by an advertising MPLS node; possibly via
>> static label mappings, static LSPs, via LDP, or via RSVP. The packet
>> would then be encapsulated based on the destination. In most cases, a
>> single label MPLS stack.
>>
>> kind regards,
>> Truman Boyes
>>
>>>> Best Regards,
>>>> Shashwat Srivastava
>>
>> On 11/04/2007, at 7:08 PM, Shashwat Srivastava wrote:
>>
>>> Hi,
>>>
>>> We are simulating an interconnection between IP network and an
>>> MPLS backbone.
>>>
>>> The approach we are taking, uses EtherType information in the LLC
>>> header to be one of
>>>
>>> IPv4 or MPLS (for packet to be sent to respective network layer).
>>>
>>>
>>>
>>> Our approach needs the previous hop information that "weather the
>>> previous nod/hop (the previous
>>>
>>> Upstream node actually) was MPLS enabled or not". This is needed to
>>> avoid 'Multiple FTN Requests
>>>
>>> Generation' at subsequent hops (the downstream nodes in the same
>>> MPLS backbone), if there is no
>>>
>>> FTN mapping found at Ingress.
>>>
>>>
>>>
>>> The same will also be needed if due to any reason the ILM mapping
>>> is not found at any Intermediate LSR,
>>>
>>> and instead of dropping the packet, we plan to forward it to IP (of
>>> course after popping up the SHIM).
>>>
>>> This will avoid any Intermediate node to start behaving as Ingress,
>>> for such packets forwarded to IP by any previous
>>>
>>> MPLS enabled node (of the same backbone).
>>>
>>>
>>>
>>> Can someone suggest whether the approach is feasible? If so, how
>>> the MAC layer will propagate the
>>>
>>> Previous hop status (MPLS enabled OR pure IPv4). Also if there is
>>> any alternative suggestion possible,
>>>
>>> Please do inform the same.
>>>
>>>
>>>
>>> Thanks and Regards,
>>>
>>> Shashwat
>>>
>>> (shashwat_iitg <at> yahoo.com)
>>
>>
>>
>>
>
>
>
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
RSS Feed