 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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) |
_______________________________________________ mpls mailing list mpls at lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls