Network Working Group R. Aggarwal Internet Draft Juniper Networks
Expiration Date: September 2007Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. November 2007 MPLS Upstream Label Assignment and Context SpecificContext-Specific Label Space draft-ietf-mpls-upstream-label-02.txtdraft-ietf-mpls-upstream-label-03.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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract RFC 3031 limits the MPLS architecture to downstream assigneddownstream-assigned MPLS labels. This document introduces the notion of upstream assignedupstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". 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 AssignedUpstream-Assigned and Downstream AssignedDownstream-Assigned Labels ...... 45 5 Assigning Upstream AssignedUpstream-Assigned Labels .................... 5 6 Distributing Upstream AssignedUpstream-Assigned Labels ................. 56 7 Upstream Neighbor Label Space and Tunnel Label Space ........................... 6 8 Context Label on LANs ................................. 79 9 Usage of Upstream AssignedUpstream-Assigned Labels ..................... 810 10 IANA Considerations ................................... 10 11 Security Considerations ............................... 10 12 Acknowledgements ...................................... 811 13 References ............................................ 9 11.111 13.1 Normative References .................................. 9 11.211 13.2 Informative References ................................ 9 1211 14 Author Information .................................... 9 1311 15 Intellectual Property Statement ....................... 10 14 Full12 16 Copyright Statement .............................. 10Notice ...................................... 12 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 downstreamdownstream- assigned MPLS labels. To quote from RFC 3031: "In the MPLS architecture, the decision to bind a particular label L to a particular FECForwarding Equivalence Class (FEC) F is made by the LSRLabel Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction." MPLS upstream labelUpstream assignment of MPLS labels has been discussed and mentioned before [RFC3353, MVPN]. However the architecture for MPLSupstream labelassignment of MPLS labels and the associated procedures have not been described. This document introduces the notion of upstream assignedupstream-assigned MPLS labels to the MPLS architecture. The procedures for upstream MPLS labelassignment of MPLS labels are described. RFC 3031 describes per-platform and per-interface label space. This document generalizes the latter to a "Context-Specific Label Space" and describes a "Neighbor Label Space" as an example of this. Upstream assignedupstream-assigned labels are always looked up in a context-specific label space. 3. Context-Specific Label Space RFC 3031 describes per-platform and per-interface label spaces. This document introduces the more general concept of a "Context-Specific Label Space". A LSR may contain one or more context-specific label spaces. In general, labels are looked up in the per-platform label space unless something about the context determines that a label be looked up in a particular context-specific label space. One example of a context-specific label space is the per-interface label space discussed in RFC 3031. When a MPLS packet is received over a particular interface the top label of the packet may need to be looked up in the receiving interface's per-interface label space. In this case the receiving interface determinesis the context of the packet. Whether MPLS packets received over a particular interface need to have their top labels looked up in a per-interface label space depends on some characteristic or configuration of the interface. There may be more than one kind of context-specific label space. Context-specific label spaces can be used for downstream assigned labels or upstream assigned labels.Per-interface label space [RFC3031] is an example of a context-specificcontext- specific label space used for downstream assigneddownstream-assigned labels. Context- specific label spaces can also be used for upstream-assigned labels, as described below. When MPLS labels are upstream assignedupstream-assigned the context of a MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a LSPLabel Switched Path (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 packetpacket, after tunnel decapsulation, is looked up in a "Tunnel Specific Label Space".label space that is specific to the root of the tunnel. This does imply that Lr be able to determine the tunnel over which the packet was received. IfTherefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping (PHP) mustMUST be disabled for the tunnel. Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received and inreceived. In this case the top label of the MPLS packetpacket, transmitted by the neighbor on LSP1, is looked up in a "Neighbor Specific Label Space". TheseThe above two examples 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. A "context label" is one which identifies a label table in which the label immediately below the context label should be looked up. A context label carried as an outermost label over a particular multi-access subnet/tunnel MUST be unique within the scope of that subnet/tunnel. 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 "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have agreed to bind Label L to a Forwarding Equivalence Class (FEC),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"."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"."upstream-assigned". An important observation about upstream-assigned labels is thatthe downstream LSR Rd that receives MPLS packets with a topfollowing. When an upstream-assigned label L is at the top of the label stack, it must be looked up by an LSR which is not the LSR that assignsassigned and distributesdistributed the label binding for L. RdTherefore an upstream-assigned label must use a context-specific label space to lookupalways be looked up in a context- specific label Lspace, as described in section 7. 4.1. Upstream AssignedUpstream-Assigned and Downstream AssignedDownstream-Assigned Labels It is possible that some LSRs on a LSP for FEC F, distribute downstream assigneddownstream-assigned label bindings for FEC F, while other LSRs distribute upstream assignedupstream-assigned label bindings. It is possible for a LSR to distribute a downstream assigneddownstream-assigned label binding for FEC F to its upstream adjacent LSR AND distribute an upstream assignedupstream-assigned label binding for FEC F to its downstream adjacent LSR. Two adjacentWhen two LSRs for aRu and Rd are adjacent on an LSP that is bound tofor FEC F, MUST use eitherF (with Ru being the upstream neighbor and Rd the downstream assignedneighbor), either Ru distributes an upstream-assigned label distributionbinding for F to Rd, or upstream assignedelse Rd distributes a downstream-assigned label distribution, for FEC F,binding to Ru, 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 AssignedUpstream-Assigned Labels The only requirement on an upstream LSR assigning upstream assignedupstream-assigned labels is that an upstream assignedupstream-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 labelslabels, for all the LSPs carried over these tunnels, from a single label spacespace, 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 identifier of these tunnels isincludes an IP address. The LSR could assign the same label value to both a downstream-assigned and an upstream- assignedupstream-assigned label. The downstream LSR always looks up upstream assignedupstream-assigned MPLS labels in a context-specific label space as described in section 7. An entry for the upstream assignedupstream-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 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. 6. Distributing Upstream AssignedUpstream-Assigned Labels Upstream-assigned label bindings MUST NOT be used unless it is known that the downstream LSR supports them. How this is known is outside the scope of this document. MPLS upstream label assignment requires a label distribution protocol to distribute the binding from the upstream LSR to the downstream LSR. Considerations that pertain to a label distribution protocol that are described in [RFC3031] apply. The distribution of the upstream-assigned labels is similar to either the ordered LSP control or independent LSP control of the downstream- assigned labels. In the former case a LSR distributes an upstream- assigned label binding for a FEC F if it is either (a) the ingress 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 SpaceIf the top label of a MPLS packet being processed by LSR Rd is upstream assigned,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 a MPLS label which is upstreamupstream- 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 stackstack, as a result of Rd processingpopping one or more labels off the label stack, from such a packet. This implies that Rd MUST be able to determine whether the top label of a MPLS packet being processed is upstream assignedupstream-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 assignedupstream-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 assignedupstream-assigned is determined by Rd by the tunnel on which the packet is received. AWhether a given tunnel can be used for transmitting either downstream assignedMPLS packets with either downstream- assigned or upstream assigned MPLS packets,labels, or both.both, depends on the tunnel type and is described in [MPLS-MCAST-ENCAPS]. 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 upstreamupstream- 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 may maintainmaintains an Upstream Neighbor Label Space" for all tunnels that have the same root. If Rd uses the"Upstream Neighbor Label Space" for upstream assigned MPLS packets transmittedlabels, assigned by Ru. When Ru to Rd,transmits MPLS packets the top label of which is upstream assigned over IP or MPLS tunnels, then Rd MUST be able to determine the root of these IP/MPLS tunnels. Rd wouldMUST then use a separate label space for each unique root. The root is identified by the head-end IP address of the Tunnel. If the same upstream router, Ru, uses different head-end IP addresses for different tunnels then the downstream router, Rd, MUST maintain a different Upstream Neighbor Label Space for each such head-end IP address. Consider the following conditions: 1) Ru is the "root" of two tunnels, call them A and B. 2) IP address X is an IP address of Ru. 3) The signaling protocol used to set up tunnel A identified A's root node as IP address X. 4) The signaling protocol used to set up tunnel B identified B's root node as IP address X. 5) Packets sent through tunnels A and B may be carrying upstream- assigned labels. 6) Ru is the LSR that assigned the upstream-assigned labels mentioned in condition 5. Under these conditions, Ru MUST use the same label space when assigning the upstream-assigned labels. Suppose that Rd is a node that belongs to tunnels A and B, but is not the root node of either tunnel. Then Rd may assume that the same upstream-assigned label space is used on both tunnels IF AND ONLY IF the signaling protocol used to set up tunnel A identified the root node as IP address X and the signaling protocol used to set up tunnel B identified the root node as the same IP address X. In addition, the protocol that is used for distributing the upstream- assigned label to be used over a particular tunnel MUST identify the "assigner" using the same IP address that is used, by the protocol that sets up the tunnel, to identify the root node of the tunnel. Implementors must take note of this, even if the tunnel setup protocol is different from the protocol that is used for distributing the upstream-assigned label to be used over the tunnel. The precise set of procedures for identifying the IP address of the root of the tunnel depend, of course, on the protocol used to set up the tunnel. For P2P tunnels, the intention is that the headend of the tunnel is the "root". For P2MP or MP2MP tunnels, one can always identify one node as being the "root" of the tunnel. Some tunnels may be set up by configuration, rather than by signaling. In these cases, the IP address of the root of the tunnel must be configured. Some tunnels may not even require configuration, e.g., a GRE tunnel can be "created" just by encapsulating packets and transmitting them. In such a case the IP address of the root is considered to be the IP source address of the encapsulated packets. If the tunnel on which Rd receives MPLS packets with a top label L is a MPLS tunnel, then Rd determines a) That L is upstream assignedupstream-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 assignedupstream-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 assignedupstream-assigned [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address in the IP header. 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 upstreamupstream- assigned or downstream assigned can be determined by Rd as described in [MPLS-MCAST-ENCAPS]. This is possible because if L is upstreamupstream- 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 upstreamupstream- 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],[RFC3032], the value of the host part of the IPv4 address is offset with 0x100x10, if the hostthis value is not greater then 0xFFFEF. Host valuesValues of the host part of the IPv4 address greater then 0xFFFEF are not allowed to be used as the context label. Consider LSRs Rm (middle)(downstream) connected to RuRu1 (upstream) on a LAN interface and to Rd (downstream)Ru2 (upstream) on a different LAN interface. Rm could receive a context label value derived from the LAN interface from RdRu1 and from Ru.Ru2. It is possible that the context label values used by RuRu1 and RdRu2 are the same. This would occur if the LAN interfaces of both RuRu1 and RdRu2 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 identifieron 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 onin the label stack. 9. Usage of Upstream AssignedUpstream-Assigned Labels A typical usage of upstream assignedupstream-assigned labels is when an upstream LSR Ru is adjacent to more thanseveral downstream LSRs <Rd1...Rdn> in a LSP LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel AND Ru wants to transmit a single copy of a MPLS packet on the LSP to <Rd1...Rdn>. In thisthe case of a tunnel Ru can distribute an upstreamupstream- assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of which is L, on the tunnel. In the case of a multi-access media or tunnel.Ru can distribute an upstream- assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit a MPLS packet, the top label of which is the context label that identifies Ru, and the label immediately below is L, on the multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS packet in the context of Ru and forward it appropriately. This implies that <Rd1..Rdn> 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 assignedupstream-assigned labels and is outside the scope of this document. 10. IANA Considerations This document has no actions for IANA. 11. Security Considerations The security considerations that apply to upstream-assigned labels and context labels are no different in kind than those that apply to downstream-assigned labels. Note that procedures for distributing upstream-assigned labels and/or context labels are not within the scope of this document. Therefore the security considerations that may apply to such procedures are not considered here. Section 8 of this document describes a procedure which enables an LSR to automatically generate a unique context label for a LAN. This procedure assumes that the IP addresses of all the LSR interfaces on the LAN will be unique in their low-order 20 bits. If two LSRs whose IP addresses have the same low-order 20 bits are placed on the LAN, other LSRs are likely to misroute packets transmitted to the LAN by either of the two LSRs in question. 12. Acknowledgements Thanks to IJsbrand Wijnands's contribution, specifically for the text on which section 8 is based. 11.13. References 184.108.40.206. 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-01.txt 11.2.draft-ietf-mpls-multicast-encaps-06.txt 13.2. Informative References [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", draft-ietf-l3vn-2547bis-mcast-02.txt 12.draft-ietf-l3vpn-2547bis-mcast-05.txt [RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi- Protocol Label Switching (MPLS) Environment.", August 2002. [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January 2001. 14. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: firstname.lastname@example.org Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: email@example.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 Email: firstname.lastname@example.org 13.15. 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. 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- email@example.com. 14. Full16. Copyright StatementNotice 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, 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.