idnits 2.17.1 draft-ietf-mpls-crldp-unnum-08.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISIS-GMPLS' is mentioned on line 79, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 79, but not defined == Missing Reference: 'CD-LDP' is mentioned on line 214, but not defined == Missing Reference: 'IANA' is mentioned on line 218, but not defined == Unused Reference: 'GMPLS-SIG' is defined on line 247, but no explicit reference was found in the text -- No information found for draft-ietf-generalized-mpls-signalling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SIG' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-02 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-03 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-11 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kireeti Kompella 3 Internet Draft Juniper Networks 4 Expiration Date: April 2003 Yakov Rekhter 5 Juniper Networks 6 Alan Kullberg 7 NetPlane Systems 9 Signalling Unnumbered Links in CR-LDP 11 draft-ietf-mpls-crldp-unnum-08.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 Current signalling used by Multi-Protocol Label Switching Traffic 37 Engineering (MPLS TE) doesn't provide support for unnumbered links. 38 This document defines procedures and extensions to Constraint-Routing 39 Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling 40 protocols, that are needed in order to support unnumbered links. 42 3. Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 4. Overview 50 Supporting MPLS TE over unnumbered links (i.e., links that do not 51 have IP addresses) involves two components: (a) the ability to carry 52 (TE) information about unnumbered links in IGP TE extensions (ISIS or 53 OSPF), and (b) the ability to specify unnumbered links in MPLS TE 54 signalling. The former is covered in [GMPLS-ISIS, GMPLS-OSPF]. The 55 focus of this document is on the latter. 57 Current signalling used by MPLS TE doesn't provide support for 58 unnumbered links because the current signalling doesn't provide a way 59 to indicate an unnumbered link in its Explicit Route Objects. This 60 document proposes simple procedures and extensions that allow CR-LDP 61 signalling [CR-LDP] to be used with unnumbered links. 63 5. Link Identifiers 65 An unnumbered link has to be a point-to-point link. An LSR at each 66 end of an unnumbered link assigns an identifier to that link. This 67 identifier is a non-zero 32-bit number that is unique within the 68 scope of the LSR that assigns it. The IS-IS and/or OSPF and RSVP 69 modules on an LSR must agree on the identifiers. 71 There is no a priori relationship between the identifiers assigned to 72 a link by the LSRs at each end of that link. 74 LSRs at the two end points of an unnumbered link exchange with each 75 other the identifiers they assign to the link. Exchanging the 76 identifiers may be accomplished by configuration, by means of a 77 protocol such as LMP ([LMP]), by means of RSVP/CR-LDP (especially in 78 the case where a link is a Forwarding Adjacency, see below), or by 79 means of IS-IS or OSPF extensions ([ISIS-GMPLS], [OSPF-GMPLS]). 81 Consider an (unnumbered) link between LSRs A and B. LSR A chooses an 82 idenfitier for that link. So is LSR B. From A's perspective we refer 83 to the identifier that A assigned to the link as the "link local 84 identifier" (or just "local identifier"), and to the identifier that 85 B assigned to the link as the "link remote identifier" (or just 86 "remote identifier"). Likewise, from B's perspective the identifier 87 that B assigned to the link is the local identifier, and the 88 identifier that A assigned to the link is the remote identifier. 90 This section is equally applicable to the case of unnumbered 91 component links (see [LINK-BUNDLE]). 93 6. Unnumbered Forwarding Adjacencies 95 If an LSR that originates an LSP advertises this LSP as an unnumbered 96 Forwarding Adjacency in IS-IS or OSPF (see [LSP-HIER]), or the LSR 97 uses the Forwarding Adjacency formed by this LSP as an unnumbered 98 component link of a bundled link (see [LINK-BUNDLE]), the LSR MUST 99 allocate an identifier to that Forwarding Adjacency (just like for 100 any other unnumbered link). Moreover, the REQUEST message used for 101 establishing the LSP that forms the Forwarding Adjacency MUST contain 102 an LSP_TUNNEL_INTERFACE_ID TLV (described below), with the LSR's 103 Router ID set to the head end's Router ID, and the Interface ID set 104 to the identifier that the LSR allocated to the Forwarding Adjacency. 106 If the REQUEST message contains the LSP_TUNNEL_INTERFACE_ID TLV, then 107 the tail-end LSR MUST allocate an identifier to that Forwarding 108 Adjacency (just like for any other unnumbered link). Furthermore, 109 the MAPPING message for the LSP MUST contain an 110 LSP_TUNNEL_INTERFACE_ID TLV, with the LSR's Router ID set to the 111 tail-end's Router ID, and the Interface ID set to the identifier 112 allocated by the tail-end LSR. 114 For the purpose of processing the ERO and the Interface ID TLV, an 115 unnumbered Forwarding Adjacency is treated as an unnumbered (TE) link 116 or an unnumbered component link as follows. The LSR that originates 117 the Adjacency sets the link local identifier for that link to the 118 value that the LSR allocates to that Forwarding Adjacency, and the 119 link remote identifier to the value carried in the Interface ID field 120 of the Reverse Interface ID TLV (for the definition of Reverse 121 Interface ID TLV see below). The LSR that is a tail-end of that 122 Forwarding Adjacency sets the link local identifier for that link to 123 the value that the LSR allocates to that Forwarding Adjacency, and 124 the link remote identifier to the value carried in the Interface ID 125 field of the Forward Interface ID TLV (for the definition of Forward 126 Interface ID see below). 128 6.1. LSP_TUNNEL_INTERFACE_ID TLV 130 The LSP_TUNNEL_INTERFACE ID TLV has Type to be determined by IETF 131 consensus and length 8. The format is given below. 133 Figure 1: LSP_TUNNEL_INTERFACE_ID TLV 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |0|0| Type | Length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | LSR's Router ID | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Interface ID (32 bits) | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 This TLV can optionally appear in either a REQUEST message or a 146 MAPPING message. In the former case, we call it the "Forward 147 Interface ID" for that LSP; in the latter case, we call it the 148 "Reverse Interface ID" for the LSP. 150 7. Signalling Unnumbered Links in EROs 152 A new Type of ER-Hop TLV of the Explicit Route Object (ERO) is used 153 to specify unnumbered links. This Type is called Unnumbered 154 Interface ID, and has the following format: 156 Figure 2: Unnumbered Interface ID 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |0|0| Type = 0x0805 | Length = 12 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 |L| Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Router ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Interface ID (32 bits) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 The Type is 0x0805 (Unnumbered Interface ID) and the Length is 12. 171 The L bit is set to indicate a loose hop, and cleared to indicate a 172 strict hop. 174 The Interface ID is the identifier assigned to the link by the LSR 175 specified by the router ID. 177 7.1. Processing the IF_ID TLV 179 When an LSR receives a REQUEST message containing the IF_ID TLV (see 180 [GMPLS-CRLDP]) with the IF_INDEX TLV, the LSR processes this TLV as 181 follows. The LSR must have information about the identifiers assigned 182 by its neighbors to the unnumbered links between the neighbors and 183 the LSR. The LSR uses this information to find a link with tuple 184 matching the tuple carried in the IF_INDEX TLV. If the matching tuple is 186 found, the match identifies the link for which the LSR has to perform 187 label allocation. 189 Otherwise, the LSR SHOULD return an error. 191 7.2. Processing the ERO 193 The Unnumbered Interface ID ER-Hop is defined to be a part of a 194 particular abstract node if that node has the Router ID that is equal 195 to the Router ID field in the Unnumbered Interface ID ER-Hop, and if 196 the node has an (unnumbered) link or an (unnumbered) Forwarding 197 Adjacency whose local identifier (from that node's point of view) is 198 equal to the value carried in the Interface ID field of the 199 Unnumbered Interface ID ER-Hop. 201 With this in mind, the ERO processing in the presence of the 202 Unnumbered Interface ID ER-Hop follows the rules specified in section 203 4.8.1 of [CR-LDP]. 205 As part of the ERO processing, or to be more precise, as part of the 206 next hop selection, if the outgoing link is unnumbered, the REQUEST 207 message that the node sends to the next hop MUST include the IF_ID 208 TLV, with the IP address field of that TLV set to the Router ID of 209 the node, and the Interface ID field of that TLV set to the 210 identifier assigned to the link by the node. 212 8. IANA Considerations 214 RFC3036 [LDP] defines the LDP TLV name space. RFC3212 [CD-LDP] 215 further subdivides the range of RFC 3036 from that TLV space for TLVs 216 associated with the CR-LDP in the range 0x0800 - 0x08FF. 218 Following the policies outlined in [IANA], TLV types in this range 219 are allocated through an IETF Consensus action. 221 This document makes the following assignments: 223 TLV Type 224 -------------------------------------- ---------- 225 UNNUMBERED_INTERFACE_ID 0x0805 226 LSP_TUNNEL_INTERFACE_ID 0x08?? 228 9. Security Considerations 230 This document extends CR-LDP and raises no new security issues. CR- 231 LDP inherits the same security mechanism described in Section 4.0 of 232 [LDP] to protect against the introduction of spoofed TCP segments 233 into LDP session connection streams. 235 10. Acknowledgments 237 Thanks to Rahul Aggarwal for his comments on the text. Thanks too to 238 Bora Akyol, Vach Kompella, and George Swallow. 240 11. References 242 11.1. Normative references 244 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 245 LDP", RFC3212, December 2001 247 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 248 Functional Description", draft-ietf-generalized-mpls- 249 signalling-08.txt 251 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 252 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt 254 [LDP] Andersson, Loa, et al., "LDP Specification" RFC3036, January 255 2001 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 11.2. Non-normative references 262 [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 263 Bundling in MPLS Traffic Engineering", draft-kompella-mpls- 264 bundle-05.txt (work in progress) 266 [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS 267 TE", draft-ietf-mpls-lsp-hierarchy-02.txt (work in progress) 269 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 270 draft-ietf-ccamp-lmp-03.txt (work in progress) 272 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 273 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 274 extensions-11.txt (work in progress) 276 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 277 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 278 gmpls-extensions-07.txt (work in progress) 280 12. Author Information 282 Kireeti Kompella 283 Juniper Networks, Inc. 284 1194 N. Mathilda Ave. 285 Sunnyvale, CA 94089 286 e-mail: kireeti@juniper.net 288 Yakov Rekhter 289 Juniper Networks, Inc. 290 1194 N. Mathilda Ave. 291 Sunnyvale, CA 94089 292 e-mail: yakov@juniper.net 294 Alan Kullberg 295 NetPlane Systems, Inc. 296 Westwood Executive Center 297 200 Lowder Brook Drive 298 Westwood, MA 02090 299 e-mail: akullber@netplane.com