--- 1/draft-ietf-mpls-upstream-label-00.txt 2007-11-14 02:24:12.000000000 +0100 +++ 2/draft-ietf-mpls-upstream-label-01.txt 2007-11-14 02:24:12.000000000 +0100 @@ -1,25 +1,24 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks -Expiration Date: August 2006 Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. - February 2006 + December 2006 MPLS Upstream Label Assignment and Context Specific Label Space - draft-ietf-mpls-upstream-label-00.txt + draft-ietf-mpls-upstream-label-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -124,82 +123,82 @@ a FEC F for a LSP LSP1. The LSR that assigns the label distributes the binding and context to a LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST be able to determine the context of this packet. An example of such a context is a Tunnel over which MPLS packets on LSP1 may be received and in this case the top label of the MPLS packet is looked up in a "Tunnel Specific Label Space". This does imply that Lr be able to determine the tunnel over which the packet was received. If the tunnel is a MPLS tunnel, penultimate-hop-popping - (PHP) must be disabled for the tunnel. Another example of such a con- - text is the neighbor from which MPLS packets on LSP1 may be received - and in this case the top label of the MPLS packet is looked up in a - "Neighbor Specific Label Space". These are further described in sec- - tion 7. + (PHP) must be disabled for the tunnel. Another example of such a + context is the neighbor from which MPLS packets on LSP1 may be + received and in this case the top label of the MPLS packet is looked + up in a "Neighbor Specific Label Space". These are further described + in section 7. There may be other sorts of contexts as well. For instance, we define the notion of a MPLS label being used to establish a context, i.e. identify a label space. 4. Upstream Label Assignment When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) - one of them can be termed an "upstream LSR" and the other a "down- - stream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have agreed - to bind Label L to a Forwarding Equivalence Class (FEC), F, for pack- - ets sent from Ru to Rd. Then with respect to this binding, Ru is the - "upstream LSR", and Rd is the "downstream LSR"." + one of them can be termed an "upstream LSR" and the other a + "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have + agreed to bind Label L to a Forwarding Equivalence Class (FEC), F, + for packets sent from Ru to Rd. Then with respect to this binding, + Ru is the "upstream LSR", and Rd is the "downstream LSR"." When the label binding for F is first made by Rd and distributed by Rd to Ru, the binding is said to be "downstream assigned". When the label binding for F is first made by Ru and distributed by Ru to Rd, the binding is said to be "upstream assigned". An important observation is that the downstream LSR Rd that receives - MPLS packets with a top label L is not the LSR that assigns and dis- - tributes label L. Rd must use a context-specific label space to + MPLS packets with a top label L is not the LSR that assigns and + distributes label L. Rd must use a context-specific label space to lookup label L as described in section 7. 4.1. Upstream Assigned and Downstream Assigned Labels - It is possible that some LSRs on a LSP for FEC F, distribute down- - stream assigned label bindings for FEC F, while other LSRs distribute - upstream assigned label bindings. It is possible for a LSR to dis- - tribute a downstream assigned label binding for FEC F to its upstream - adjacent LSR AND distribute an upstream assigned label binding for - FEC F to its downstream adjacent LSR. Two adjacent LSRs for a LSP - that is bound to FEC F, MUST use either downstream assigned label - distribution or upstream assigned label distribution, for FEC F, but - NOT both. How these LSRs will determine which of the two is to be - used is outside the scope of this document. + It is possible that some LSRs on a LSP for FEC F, distribute + downstream assigned label bindings for FEC F, while other LSRs + distribute upstream assigned label bindings. It is possible for a LSR + to distribute a downstream assigned label binding for FEC F to its + upstream adjacent LSR AND distribute an upstream assigned label + binding for FEC F to its downstream adjacent LSR. Two adjacent LSRs + for a LSP that is bound to FEC F, MUST use either downstream assigned + label distribution or upstream assigned label distribution, for FEC + F, but NOT both. How these LSRs will determine which of the two is to + be used is outside the scope of this document. 5. Assigning Upstream Assigned Labels The only requirement on an upstream LSR assigning upstream assigned labels is that an upstream assigned label must be unambiguous in the context-specific label space in which the downstream LSR will look it up. An upstream LSR which is the head end of multiple tunnels SHOULD by default assign the upstream-assigned labels from a single label space which is common to all those tunnels. Further an upstream LSR which is the head of multiple tunnels SHOULD use the same IP address - as the head identifier of these tunnels, provided that the head iden- - tifier of these tunnels is an IP address. The LSR could assign the - same label value to both a downstream-assigned and an upstream- + as the head identifier of these tunnels, provided that the head + identifier of these tunnels is an IP address. The LSR could assign + the same label value to both a downstream-assigned and an upstream- assigned label. The downstream LSR always looks up upstream assigned MPLS labels in a context-specific label space as described in section 7. An entry for the upstream assigned labels is not created in the Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these - labels are not incoming labels. Instead an upstream label is an out- - going label, with respect to the upstream LSR, for MPLS packets + labels are not incoming labels. Instead an upstream label is an + outgoing label, with respect to the upstream LSR, for MPLS packets transmitted on the MPLS LSP in which the upstream LSR is adjacent to the downstream LSR. Hence an upstream label is part of a Next Hop Label Forwarding Entry (NHLFE) at the upstream LSR. When Ru advertises a binding of label L for FEC F to Rd, it creates a NHLFE entry corresponding to L. This NHLFE entry results in imposing the label L on the MPLS label stack of the packet forwarded using the NHLFE entry. If Ru is a transit router on the LSP for FEC F, it binds the ILM for the LSP to this NHLFE. If Ru is an ingress router on the LSP for FEC F, it binds the FEC to the NHLFE entry. @@ -234,40 +233,40 @@ context-specific label space, not in a per-platform label space. Rd uses a context-specific label space that it maintains for Ru to "reserve" MPLS labels assigned by Ru. Hence if Ru distributes an upstream assigned label binding L for FEC F to Rd, then Rd reserves L in the separate ILM for Ru's context-specific label space. This is the ILM that Rd uses to lookup MPLS packets received from Ru, the top label of which is upstream assigned by Ru. This implies that Rd MUST be able to determine whether the top label - of a received MPLS packet is upstream assigned and if yes, the "con- - text" of this packet. How this determination is made depends on the - mechanism that is used by Ru to transmit the MPLS packet with an + of a received MPLS packet is upstream assigned and if yes, the + "context" of this packet. How this determination is made depends on + the mechanism that is used by Ru to transmit the MPLS packet with an upstream assigned top label L, to Rd. Ru may transmit this packet to - Rd by encapsulating it directly in a data link frame or by transmit- - ting it in an IP or MPLS tunnel. + Rd by encapsulating it directly in a data link frame or by + transmitting it in an IP or MPLS tunnel. If Ru transmits this packet by encapsulating it in a data link frame, - then whether L is upstream assigned or downstream assigned is deter- - mined by Rd as described in [MPLS-MCAST-ENCAPS]. If L is upstream - assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the - data link frame. Rd maintains a separate "Upstream Neighbor Label - Space" for Ru. The "context" of this packet i.e. the upstream neigh- - bor label space, in which L was reserved is determined by the data - link header. For example if the data link header is ethernet, the - source MAC address is used to determine the context. + then whether L is upstream assigned or downstream assigned is + determined by Rd as described in [MPLS-MCAST-ENCAPS]. If L is + upstream assigned then [MPLS-MCAST-ENCAPS] uses a different ether + type in the data link frame. Rd maintains a separate "Upstream + Neighbor Label Space" for Ru. The "context" of this packet i.e. the + upstream neighbor label space, in which L was reserved is determined + by the data link header. For example if the data link header is + ethernet, the source MAC address is used to determine the context. - If Ru transmits this packet by encapsulating it in an IP or MPLS tun- - nel, then the fact that L is upstream assigned is determined by Rd by - the tunnel on which the packet is received. A given tunnel can be + If Ru transmits this packet by encapsulating it in an IP or MPLS + tunnel, then the fact that L is upstream assigned is determined by Rd + by the tunnel on which the packet is received. A given tunnel can be used for transmitting either downstream assigned MPLS packets or upstream assigned MPLS packets, or both. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream assigned MPLS labels. The description of such a mechanism is outside the scope of this document. When Rd receives MPLS packets with a top label L on such a tunnel, it determines the "context" of this packet based on the tunnel that the packet is received on. Rd may maintain a separate "Tunnel Label Space" for the tunnel or it @@ -305,23 +304,23 @@ for determining this are specific to the application that is using upstream assigned labels and is outside the scope of this document. 9. References 9.1. Normative References [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, RFC 3031. - [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- + [RFC2119] "Key words for use in RFCs to Indicate Requirement [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, - draft-rosen-mpls-codepoint-00.txt + draft-ietf-mpls-codepoint-00.txt 9.2. Informative References [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs" 10. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. @@ -344,36 +343,36 @@ The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. - Copies of IPR disclosures made to the IETF Secretariat and any assur- - ances of licenses to be made available, or the result of an attempt - made to obtain a general license or permission for the use of such - proprietary rights by implementers or users of this specification can - be obtained from the IETF on-line IPR repository at + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 12. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- - MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES - OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.