--- 1/draft-ietf-mpls-upstream-label-01.txt 2007-11-14 02:24:26.000000000 +0100 +++ 2/draft-ietf-mpls-upstream-label-02.txt 2007-11-14 02:24:26.000000000 +0100 @@ -1,24 +1,23 @@ Network Working Group R. Aggarwal Internet Draft Juniper Networks +Expiration Date: September 2007 Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. - December 2006 - MPLS Upstream Label Assignment and Context Specific Label Space - draft-ietf-mpls-upstream-label-01.txt + draft-ietf-mpls-upstream-label-02.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 @@ -47,27 +46,29 @@ Table of Contents 1 Specification of requirements ......................... 2 2 Introduction .......................................... 2 3 Context-Specific Label Space .......................... 3 4 Upstream Label Assignment ............................. 4 4.1 Upstream Assigned and Downstream Assigned Labels ...... 4 5 Assigning Upstream Assigned Labels .................... 5 6 Distributing Upstream Assigned Labels ................. 5 7 Upstream Neighbor Label Space and Tunnel Label Space .. 6 - 8 Usage of Upstream Assigned Labels ..................... 7 - 9 References ............................................ 8 - 9.1 Normative References .................................. 8 - 9.2 Informative References ................................ 8 -10 Author Information .................................... 8 -11 Intellectual Property Statement ....................... 9 -12 Full Copyright Statement .............................. 9 + 8 Context Label on LANs ................................. 7 + 9 Usage of Upstream Assigned Labels ..................... 8 +10 Acknowledgements ...................................... 8 +11 References ............................................ 9 +11.1 Normative References .................................. 9 +11.2 Informative References ................................ 9 +12 Author Information .................................... 9 +13 Intellectual Property Statement ....................... 10 +14 Full Copyright Statement .............................. 10 1. Specification of requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction RFC 3031 [RFC3031] limits the MPLS architecture to downstream @@ -221,48 +222,38 @@ LSR for FEC F, or (b) if it has already received an upstream label binding for that FEC from its adjacent upstream LSR for FEC F, or (c) if it has received a request for a downstream label binding from its upstream adjacent LSR. In the latter case each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind an upstream-assigned label to that FEC and to distribute that binding to its label distribution peers. 7. Upstream Neighbor Label Space and Tunnel Label Space - If the top label of an MPLS packet is upstream assigned, when the - packet is received by LSR Rd the label is looked up in a - context-specific label space, not in a per-platform label space. + If the top label of a MPLS packet being processed by LSR Rd is + upstream assigned, the label is looked up in a 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. + the ILM that Rd uses to lookup a MPLS label which is upstream + assigned by Ru. This label may be the top label on the label stack of + a packet received from Ru or it may be exposed as the top label on + the label stack as a result of Rd processing such a packet. 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 + of a MPLS packet being processed 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 - 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 - 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. + upstream assigned top label L, to Rd. 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 @@ -281,72 +272,135 @@ a MPLS tunnel, then Rd determines a) That L is upstream assigned and b) The context for L, from the labels above L in the label stack. Note that one or more of these labels may also be upstream assigned labels. If the tunnel on which Rd receives MPLS packets with a top label L is an IP/GRE tunnel then Rd determines a) That L is upstream assigned [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address in the IP header. -8. Usage of Upstream Assigned Labels + When Ru and Rd are adjacent to each other on a multi-access data link + media, if Ru would transmit the packet, with top label L, by + encapsulating it in a data link frame, then whether L is upstream + assigned or downstream assigned can be determined by Rd as described + in [MPLS-MCAST-ENCAPS]. This is because if L is upstream assigned + then [MPLS-MCAST-ENCAPS] uses a different ether type in the data link + frame. However this is not sufficient for Rd to determine the context + of this packet. In order for Rd to determine the context of this + packet, Ru encapsulates the packet, in a one hop MPLS tunnel. This + tunnel uses an MPLS context label that is assigned by Ru. Section 8 + describes how the context label is assigned. Rd maintains a separate + "Upstream Neighbor Label Space" for Ru. The "context" of this packet, + i.e. Ru's upstream neighbor label space, in which L was reserved, is + determined by Rd from the top context label and the interface on + which the packet is received. The ether type in the data link frame + is set to indicate that the top label is upstream assigned. The + second label in the stack is L. + +8. Context Label on LANs + + The procedure described below applies to LSRs using IPv4 and does not + apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside + the scope of this document. + + For a labeled packet with an ether type of 'upstream label + assignment' the top label is used as the context. The context label + value is assigned by the upstream LSR and advertised to the + downstream LSRs. Mechanisms for advertising the context label are + outside the scope of this document. + + The context label assigned by a LSR on a LAN interface MUST be unique + across all the context labels assigned by other LSRs on the same LAN. + Each LAN interface is normally configured with a primary IPv4 address + that is unique on that LAN. The host part of the IPv4 address, + identified by the network mask, is unique. If the IPv4 network mask + is greater then 12 bits, it is possible to map the remaining 20 bits + into an unique context label value. This enables the LSRs on the LAN + to assign an unique context label without the need for additional + configuration. To avoid assigning context label values that fall into + the reserved label space range [RFC 3032], the value of the host is + offset with 0x10 if the host is not greater then 0xFFFEF. Host values + greater then 0xFFFEF are not allowed to be used as the context label. + + Consider LSRs Rm (middle) connected to Ru (upstream) on a LAN + interface and to Rd (downstream) on a different LAN interface. Rm + could receive a context label value derived from the LAN interface + from Rd and from Ru. It is possible that the context label values + used by Ru and Rd are the same. This would occur if the LAN + interfaces of both Ru and Rd are configured with a primary IPv4 + address where the lowest 20 bits are equal. To avoid these conflicts + the context label MUST be looked up in the context of the LAN + interface identifier on which the packet is received. A receiving LSR + that receives a packet with a context label of Lc over LAN interface + identified by X, MUST use the label space specific to X to lookup Lc. + This determines the context to lookup the label below Lc on the label + stack. + +9. Usage of Upstream Assigned Labels A typical usage of upstream assigned labels is when an upstream LSR Ru is adjacent to more than downstream LSRs in a LSP LSP1 AND Ru is connected to via a multi-access media or tunnel AND Ru wants to transmit a single copy of a MPLS packet on the LSP to . In this case Ru can distribute an upstream assigned label L that is bound to the FEC for LSP1, to and transmit a MPLS packet, the top label of which is L, on the multi-access media or tunnel. Each of will then interpret this MPLS packet in the context of Ru and forward it appropriately. This implies that MUST all be able to support an Upstream Neighbor Label Space for Ru and Ru MUST be able to determine this. The mechanisms for determining this are specific to the application that is using upstream assigned labels and is outside the scope of this document. -9. References +10. Acknowledgements -9.1. Normative References + Thanks to IJsbrand Wijnands's contribution, specifically for the text + on which section 8 is based. + +11. References + +11.1. Normative References [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, RFC 3031. [RFC2119] "Key words for use in RFCs to Indicate Requirement [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, - draft-ietf-mpls-codepoint-00.txt + draft-ietf-mpls-codepoint-01.txt -9.2. Informative References +11.2. Informative References - [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs" + [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", + draft-ietf-l3vn-2547bis-mcast-02.txt -10. Author Information +12. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 Email: erosen@cisco.com -11. Intellectual Property Statement +13. Intellectual Property Statement 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. @@ -356,23 +410,23 @@ 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 +14. 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. + Copyright (C) The IETF Trust (2007). 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 - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, 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.