diff options
Diffstat (limited to 'doc/rfc/rfc3480.txt')
| -rw-r--r-- | doc/rfc/rfc3480.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3480.txt b/doc/rfc/rfc3480.txt new file mode 100644 index 0000000..8cd15db --- /dev/null +++ b/doc/rfc/rfc3480.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group K. Kompella +Request for Comments: 3480 Y. Rekhter +Category: Standards Track Juniper Networks + A. Kullberg + NetPlane Systems + February 2003 + + + Signalling Unnumbered Links in CR-LDP + (Constraint-Routing Label Distribution Protocol) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + Current signalling used by Multi-Protocol Label Switching Traffic + Engineering (MPLS TE) does not provide support for unnumbered links. + This document defines procedures and extensions to Constraint-Routing + Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling + protocols that are needed in order to support unnumbered links. + +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 BCP 14, RFC 2119 + [RFC2119]. + +1. Overview + + Supporting MPLS TE over unnumbered links (i.e., links that do not + have IP addresses) involves two components: (a) the ability to carry + (TE) information about unnumbered links in IGP TE extensions (ISIS or + OSPF), and (b) the ability to specify unnumbered links in MPLS TE + signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The + focus of this document is on the latter. + + + + + +Kompella, et al. Standards Track [Page 1] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + + Current signalling used by MPLS TE does not provide support for + unnumbered links because the current signalling does not provide a + way to indicate an unnumbered link in its Explicit Route Objects. + This document proposes simple procedures and extensions that allow + CR-LDP signalling [CR-LDP] to be used with unnumbered links. + +2. Link Identifiers + + An unnumbered link has to be a point-to-point link. An LSR at each + end of an unnumbered link assigns an identifier to that link. This + identifier is a non-zero 32-bit number that is unique within the + scope of the LSR that assigns it. If one is using OSPF or ISIS as + the IGP in support of traffic engineering, then the IS-IS and/or OSPF + and CR-LDP modules on an LSR must agree on the identifiers. + + There is no a priori relationship between the identifiers assigned to + a link by the LSRs at each end of that link. + + LSRs at the two end points of an unnumbered link exchange with each + other the identifiers they assign to the link. Exchanging the + identifiers may be accomplished by configuration, by means of a + protocol such as LMP ([LMP]), by means of CR-LDP (especially in the + case where a link is a Forwarding Adjacency, see below), or by means + of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). + + Consider an (unnumbered) link between LSRs A and B. LSR A chooses an + identifier for that link. So does LSR B. From A's perspective, we + refer to the identifier that A assigned to the link as the "link + local identifier" (or just "local identifier"), and to the identifier + that B assigned to the link as the "link remote identifier" (or just + "remote identifier"). Likewise, from B's perspective, the identifier + that B assigned to the link is the local identifier, and the + identifier that A assigned to the link is the remote identifier. + + In the context of this document, the term "Router ID" means a stable + IP address of an LSR that is always reachable if there is any + connectivity to the LSR. This is typically implemented as a + "loopback address"; the key attribute is that the address does not + become unusable if an interface on the LSR is down. In some cases, + this value will need to be configured. If one is using OSPF or ISIS + as the IGP in support of traffic engineering, then it is RECOMMENDED + for the Router ID to be set to the "Router Address" as defined in + [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS- + TE]. + + This section is equally applicable to the case of unnumbered + component links (see [LINK-BUNDLE]). + + + + +Kompella, et al. Standards Track [Page 2] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + +3. Unnumbered Forwarding Adjacencies + + If an LSR that originates an LSP advertises this LSP as an unnumbered + Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR + uses the Forwarding Adjacency formed by this LSP as an unnumbered + component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST + allocate an identifier to that Forwarding Adjacency (just like for + any other unnumbered link). Moreover, the REQUEST message used for + establishing the LSP that forms the Forwarding Adjacency MUST contain + an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's + Router ID set to the head end's Router ID, and the Interface ID set + to the identifier that the LSR allocated to the Forwarding Adjacency. + + If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then + the tail-end LSR MUST allocate an identifier to that Forwarding + Adjacency (just like for any other unnumbered link). Furthermore, + the MAPPING message for the LSP MUST contain an + LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the + tail-end's Router ID, and the Interface ID set to the identifier + allocated by the tail-end LSR. + + For the purpose of processing the Explicit Route TLV and the + Interface ID TLV, an unnumbered Forwarding Adjacency is treated as an + unnumbered (TE) link or an unnumbered component link as follows. The + LSR that originates the Adjacency sets the link local identifier for + that link to the value that the LSR allocates to that Forwarding + Adjacency, and the link remote identifier to the value carried in the + Interface ID field of the Reverse Interface ID TLV (for the + definition of Reverse Interface ID TLV see below). The LSR that is a + tail-end of that Forwarding Adjacency sets the link local identifier + for that link to the value that the LSR allocates to that Forwarding + Adjacency, and the link remote identifier to the value carried in the + Interface ID field of the Forward Interface ID TLV (for the + definition of Forward Interface ID see below). + + + + + + + + + + + + + + + + + +Kompella, et al. Standards Track [Page 3] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + +3.1. LSP_TUNNEL_INTERFACE_ID TLV + + The LSP_TUNNEL_INTERFACE ID TLV has Type 0x0836 and length 8. The + format is given below. + + Figure 1: LSP_TUNNEL_INTERFACE_ID TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|0| Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LSR's Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID (32 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV can optionally appear in either a REQUEST message or a + MAPPING message. In the former case, we call it the "Forward + Interface ID" for that LSP; in the latter case, we call it the + "Reverse Interface ID" for the LSP. + +4. Signalling Unnumbered Links in Explicit Route TLV + + A new Type of ER-Hop TLV of the Explicit Route TLV is used to specify + unnumbered links. This Type is called Unnumbered Interface ID, and + has the following format: + + The Type is 0x0837, and the Length is 12. The L bit is set to + indicate a loose hop, and cleared to indicate a strict hop. + + The Interface ID is the identifier assigned to the link by the LSR + specified by the router ID. + + Figure 2: Unnumbered Interface ID + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0|0| Type | Length = 12 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |L| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID (32 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Kompella, et al. Standards Track [Page 4] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + +4.1. Processing the IF_ID TLV + + When an LSR receives a REQUEST message containing the IF_ID + (Interface ID) TLV (see [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR + processes this TLV as follows. The LSR must have information about + the identifiers assigned by its neighbors to the unnumbered links + between the neighbors and the LSR. The LSR uses this information to + find a link with tuple <Router ID, local identifier> matching the + tuple <IP Address, Interface ID> carried in the IF_INDEX TLV. If the + matching tuple is found, the match identifies the link for which the + LSR has to perform label allocation. + + Otherwise, the LSR SHOULD return an error. + +4.2. Processing the Unnumbered Interface ID ER-Hop TLV + + The Unnumbered Interface ID ER-Hop is defined to be a part of a + particular abstract node if that node has the Router ID that is equal + to the Router ID field in the Unnumbered Interface ID ER-Hop, and if + the node has an (unnumbered) link or an (unnumbered) Forwarding + Adjacency whose local identifier (from that node's point of view) is + equal to the value carried in the Interface ID field of the + Unnumbered Interface ID ER-Hop. + + With this in mind, the Explicit Route TLV processing in the presence + of the Unnumbered Interface ID ER-Hop follows the rules specified in + section 4.8.1 of [CR-LDP]. + + As part of the Explicit Route TLV processing, or to be more precise, + as part of the next hop selection, if the outgoing link is + unnumbered, the REQUEST message that the node sends to the next hop + MUST include the IF_ID TLV, with the IP address field of that TLV set + to the Router ID of the node, and the Interface ID field of that TLV + set to the identifier assigned to the link by the node. + +5. IANA Considerations + + RFC 3036 [LDP] defines the LDP TLV name space. RFC 3212 [CD-LDP] + further subdivides the range of that TLV space for TLVs associated + with the CR-LDP in the range 0x0800 - 0x08FF, and defines the rules + for the assignment of TLVs within that range using the terminology of + BCP 26, RFC 2434, "Guidelines for Writing an IANA Considerations + Section in RFCs". Those rules apply to the assignment of TLV Types + for the Unnumbered Interface ID and LSP_TUNNEL_INTERFACE_ID TLVs + defined in this document. + + + + + + +Kompella, et al. Standards Track [Page 5] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + +6. Security Considerations + + This document extends CR-LDP and raises no new security issues. CR- + LDP inherits the same security mechanism described in Section 4.0 of + [LDP] to protect against the introduction of spoofed TCP segments + into LDP session connection streams. + +7. Acknowledgments + + Thanks to Rahul Aggarwal for his comments on the text. Thanks also + to Bora Akyol, Vach Kompella, and George Swallow. + +8. References + +8.1. Normative References + + [CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, + L., Doolan, P., Worster, T., Feldman, N., Fredette, A., + Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. + Malis, "Constraint-Based LSP Setup using LDP", RFC + 3212, January 2002. + + [GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching + (GMPLS) Signaling Functional Description", RFC 3471, + January 2003. + + [GMPLS-CRLDP] Ashwood, P., Ed. and L. Berger, "Generalized Multi- + Protocol Label Switching (GMPLS) Signaling Constraint- + based Routed Label Distribution Protocol (CR-LDP) + Extensions", RFC 3472 January 2003. + + [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. + and B. Thomas, "LDP Specification", RFC 3036, January + 2001 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +8.2. Informative References + + [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link + Bundling in MPLS Traffic Engineering", Work in + Progress. + + [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS + TE", Work in Progress. + + + + + +Kompella, et al. Standards Track [Page 6] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + + [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol + (LMP)", Work in Progress. + + [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS + Extensions in Support of Generalized MPLS", Work in + Progress. + + [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF + Extensions in Support of Generalized MPLS", Work in + Progress. + + [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering + Extensions to OSPF Version 2", Work in Progress. + + [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic + Engineering", Work in Progress. + +9. Authors' Addresses + + Kireeti Kompella + Juniper Networks, Inc. + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + + EMail: kireeti@juniper.net + + Yakov Rekhter + Juniper Networks, Inc. + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + + EMail: yakov@juniper.net + + Alan Kullberg + NetPlane Systems, Inc. + Westwood Executive Center + 200 Lowder Brook Drive + Westwood, MA 02090 + + EMail: akullber@netplane.com + + + + + + + + + + + +Kompella, et al. Standards Track [Page 7] + +RFC 3480 Signalling Unnumbered Links in CR-LDP February 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Kompella, et al. Standards Track [Page 8] + |