Subject: [mpls] Previous Node information in MPLS enabled node (LSR)

From: "Shashwat Srivastava" <[email-masked]>
Date: Wed, 11 Apr 2007 16:43:36 +0530

Hi Truman,

  Thanks for the response. Please find my comments inline.

-----Original Message-----

From: Truman Boyes [mailto:[email-masked]] 

Sent: Wednesday, April 11, 2007 3:04 PM

To: Shashwat Srivastava

Cc: [email-masked]; [email-masked]

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

> ([email-masked])

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls