doc: Add RFC documents

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]
+