idnits 2.17.1 draft-guo-rsvp-te-extensions-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 385 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 64 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 136 has weird spacing: '...ON that remai...' -- 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: 'SONET' is mentioned on line 67, but not defined -- No information found for draft-ietf-mpls-revp-lsp-tunnel - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVP-TE' -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ARCH' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-03 == Outdated reference: A later version (-01) exists of draft-bms-optical-sdhsonet-mpls-control-frmwrk-00 -- Possible downref: Normative reference to a draft: ref. 'BMS' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-recovery-frmwrk-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-recovery-frmwrk (ref. 'RECOV') == Outdated reference: A later version (-02) exists of draft-many-inference-srlg-00 -- Possible downref: Normative reference to a draft: ref. 'SRLG' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Dan Guo, Jibin Zhan, 2 Internet Draft Nanda Ravindran, Prakash Siva 3 draft-guo-rsvp-te-extensions-00.txt Wenjing Chu, Robert Cooper 4 July 2001 (Turin Networks) 6 Expiration Date Jan 2002 Raymond Cheung, James Fu 7 (Sorrento Networks) 9 Extensions to RSVP-TE for Supporting Diverse Path Protection 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 1. Abstract 34 This draft describes two specific extensions to RSVP-TE. The first 35 extension is concerned about the scalability of RSVP-TE. It proposes 36 expanding the length of tunnel ID in RSVP-TE session object, from 16 37 bits to 32 bits, in order to increase the upper limit of LSPs origin- 38 ated from one node. The second extension is to propose a new object 39 for representing a protection group. A protection group can tie two 40 or more diverse LSPs between a source-destination pair of nodes. This 41 extension is warranted due to the importance and wide-spread appli- 42 cations of LSP protection switching mechanisms. With this extension, 43 protection group information no longer is embedded into vendor-specific 44 opaque objects. These two extensions only require minor changes to RSVP- 45 TE protocol. When adopted into RSVP-TE, they will improve the scalability 46 of RSVP-TE and simplify the support of diverse LSP protection mechanisms. 48 2. Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC-2119. 54 3. Introduction 56 The Generalized MPLS (GMPLS) extends MPLS to encompass TDM (e.g., SONET 57 /SDH), Lambda Switch (LSC) and Fiber-Switching (FSC) [GMPLS-ARCH]. RSVP- 58 TE, a GMPLS-based signaling protocol, is required to handle the signaling 59 for provisioning of Label Switched Paths (LSPs) at a wide range of granu- 61 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 1] 63 larities [RSVP-TE][GMPLS-RSVP]. For example, SONET and SDH are two TDM 64 standards widely used by operators to transport signals multiplexed over 65 optical links. They possess a multiplexing hierarchy that includes a 66 coarse circuit such as STS-48 and a fine-granularity circuit such as VT 67 1.5 [SONET]. As a result, it is of importance for RSVP-TE to be scalable 68 in supporting a variety of switching technologies. 70 Additionally, there have been considerable efforts towards devising the 71 mechanism for supporting LSP protection and restoration. In the case of 72 optical transport networks (OTN), protection and restoration of transport 73 circuits is a capability universally required [BMS][RECOV]. With the 74 consideration of shared risk link group (SRLG) properties (see [SRLG]), 75 two or more diverse circuits can be provisioned between a pair of nodes, 76 to support various protection switching schemes (e.g., 1+1, 1:1, 1:n, m:n). 78 The goal of this draft is to describe two specific extensions to RSVP- 79 TE. The first extension is concerned about the scalability of RSVP-TE. 80 It proposes expanding the length of tunnel ID in RSVP-TE session object, 81 from 16 bits to 32 bits, in order to increase the upper limit of LSPs 82 originated from one node. In the latest RSVP-TE draft, tunnel ID occupies 83 32 bits but the higher 16 bits is mandated to be 0. This extension will 84 greatly extend the addressing space for tunnel ID. 86 The second extension is to propose a new object for representing a pro- 87 tection group. The protection group is a concept for tying two or more 88 diverse LSPs between a source-destination pair of nodes. This extension 89 is warranted due to the importance and wide-spread applications of the 90 LSP protection capability. For 1+1 or 1:1 protection switching schemes, 91 one LSP is a working LSP and the other LSP is the protection LSP. For 92 1:N (or M:N) protection switching scheme, one LSP (or M LPSs) is the 93 protection LSP shared by N working LSPs. Without this extension, the 94 current approach is to have each vendor create private (opaque) objects 95 for representing this information. This approach impairs the inter- 96 operability, since different nodes may be from different vendors using 97 different coding schemes. 99 These two extensions only require minor changes to RSVP-TE protocol. Their 100 implementation is straight-forward. When adopted into RSVP-TE, they will 101 improve the scalability of RSVP-TE and simplify the support of diverse LSP 102 protection mechanisms. 104 4. Extension 1: 32 Bits for Tunnel ID 106 An RSVP session is uniquely identified by a destination IP address, a 107 tunnel ID, an LSP ID, and an extended tunnel ID. An extended tunnel ID 108 is usually set to the source node IP address. An LSP ID is commonly 109 used for supporting the "make-before-break" feature. 111 Currently, RSVP-TE uses 16 bits to represent a tunnel ID while the 16 112 bits immediate to its left are mandated to be 0 [RSVP-TE]. 114 LSP_TUNNEL_IPv4 Session Object 116 Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 118 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 2] 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | IPv4 tunnel end point address | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | MUST be zero | Tunnel ID | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Extended Tunnel ID | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 IPv4 tunnel end point address 132 IPv4 address of the egress node for the tunnel. 134 Tunnel ID 136 A 16-bit identifier used in the SESSION that remains constant 137 over the life of the tunnel. 139 For SONET/SDH, 16 bits are not enough. For example, at the VT 1.5 level, 140 under current specifications, a node can have at most 1.5Mps*2**16, 141 which is 96 Gbps. If a SONET node has more than 100 Gbps of combined 142 throughput, we may run out of the available tunnel IDs. 144 We propose a simple modification that allows tunnel ID to occupy 32 bits: 146 Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | IPv4 tunnel end point address | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Tunnel ID (32 bits) | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Extended Tunnel ID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Tunnel ID 159 A 32-bit identifier used in the SESSION that remains constant 160 over the life of the tunnel. 162 5. Extension 2: Protection Group object 164 As discussed in section 3, two or more diverse paths are often provisioned 165 between a node-pair. Diverse paths are obtained by applying the SRLG 166 constraint criteria to the constraint-based path computation. They take 167 into account resource and logical structure disjointness that implies a 168 lower probability of simultaneous lightpath failure. Diverse paths can 169 form a protection group for providing various protection switching schemes 170 (including 1+1, 1:1, 1:N, M:N). A protection path in a protection group 171 can carry traffic identical to working traffic, or carry extra traffic, or 172 simply stand by. 174 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 3] 176 When a protection group is formed and provisioned, it is assigned an 177 identifier (ID) by the traffic engineering (TE) manager. A protection 178 group is uniquely defined by . 181 A protection group contains a collection of LSPs. For example, one 182 primary LSP and one protection LSP for 1:1 or 1+1 protection schemes, 183 or N working LSPs and one protection LSP for 1:N protection. 185 We propose to add a new object for representing a protection group (PG). 186 The protection group provides a way to bond a number of LSPs together. 187 It is an optional object at the path level. 189 ::= [ ] 190 191 [ ] 192 [ ] 193 [ PROTECTION_GROUP_OBJ ] 194 195 [ ] 196 [ ... ] 197 199 Class: TBD; C-type: TBD; 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |F| Type| Index | reserved | M | N | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | PROTECTION GROUP ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 F: 1 bit Flag to indicate whether this path is protection or working; 210 F=0: working path; 211 F=1: protection path; 213 Type: 3-bit field, to indicate protection type; 214 0: 1+1; 215 1: 1:1; 216 2: 1:N; 217 3: M:N 218 Index: 4-bit field to indicate the rank of this path. 220 For example, when F=0 (i.e., working path), Type is 2 (i.e.,1:N) and 221 index =2, it means this path is the 2nd working. 223 Reserved: 8-bit field for future usage. 225 M: 8-bit field. 226 N: 8-bit field. 228 When type=0 (i.e., 1+1) or type=1 (i.e., 1:1), M and N must be 0; 229 When type=2 (i.e., 1:N), M must be 0 and N can be 0 to 255; 230 When type=3 (i.e., M:N), M and N can be 0 to 255. 232 Protection Group ID: 32-bit field to identify a protection group together 233 with source ID and destination ID. 235 Additional information regarding traffic types, such as extra traffic or Non- 236 preemptible Unprotected Traffic (NUT), can be added into this object. This is 237 left for future study. 239 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 4] 241 When a node receives a path message which contains the protection 242 group object, it can extract the protection information regarding 243 this path and pass it to the traffic engineering (TE) manager. It is 244 up to the TE manager to match all the diverse paths belonging to 245 the same protection group. 247 6. Security Considerations 249 The extensions specified here do not raise any security issues that 250 are not already present in the RSVP-TE architecture. 252 7. References 254 [ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description 255 Including Multiplex Structure, Rates, and Formats," ANSI 256 T1.105, 2000. 258 [RSVP-TE] Awduche, D, et al, "RSVP-TE: Extensions to RSVP for LSP 259 Tunnels", Internet Draft, Work in Progress, draft-ietf-mpls-revp-lsp- 260 tunnel-08.txt, May 2001. 262 [GMPLS-ARCH] E. Mannie et al., "Generalized Multi-Protocol Label 263 Switching (GMPLS) Architecture", Internet Draft, Work in progress, 264 draft-many-gmpls-architecture-00.txt, February 2001. 266 [GMPLS-SONET/SDH] E. Mannie Editor, "GMPLS Extensions for SONET and 267 SDH Control," Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt, 268 June 2001. 270 [GMPLS-RSVP] P. Ashwood-Smith et al., "Generalized MPLS Signaling 271 - RSVP-TE Extensions", Internet Draft, Work in progress, draft-ietf- 272 mpls-generalized-rsvp-te-03.txt, May 2001. 274 [BMS] G. Bernstein et al, "Framework for MPLS-based Control of Optical 275 SDH/SONET Networks", Internet Draft, draft-bms-optical-sdhsonet-mpls- 276 control-frmwrk-00.txt, November 2000 278 [RECOV] V. Sharma, et al, "Framework for MPLS-based Recovery," Internet 279 Draft, draft-ietf-mpls-recovery-frmwrk-02.txt, March 2001. 281 [SRLG] D. Papadimitriou, et al, "Inference of Shared Risk LInk Groups," 282 Internet Draft, draft-many-inference-srlg-00.txt, Aug 2001. 284 8. Author's Addresses 286 Dan Guo, Jibin Zhan, N. Ravindran, P. Siva, Wenjing Chu, R. Cooper 287 Turin Networks, Inc. 288 1415 N. McDowell Blvd, Petaluma, CA 95454 289 Phone: +1 707-665-4357 290 Email: {dguo,jzhan,nravindran, psiva,wchu,rcooper}@turinnetworks.com 292 Raymond Cheung, James Fu 293 Sorrento Networks, Inc. 294 9990 Mesa Rim Road, 295 San Diego, CA 92121 296 Email: {rcheung,jfu}@sorrentonet.com 298 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 5] 300 9. Full Copyright Notice 302 Copyright (C) The Internet Society (1997). All Rights Reserved. 304 This document and translations of it may be copied and furnished to others, 305 and derivative works that comment on or otherwise explain it or assist in 306 its implementation may be prepared, copied, published and distributed, in 307 whole or in part, without restriction of any kind, provided that the above 308 copyright notice and this paragraph are included on all such copies and 309 derivative works. However, this document itself may not be modified in any 310 way, such as by removing the copyright notice or references to the Internet 311 Society or other Internet organizations, except as needed for the purpose 312 of developing Internet standards in which case the procedures for copyrights 313 defined in the Internet Standards process must be followed, or as required 314 to translate it into languages other than English. 316 The limited permissions granted above are perpetual and will not be revoked 317 by the Internet Society or its successors or assigns. 319 This document and the information contained herein is provided on an "AS IS" 320 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 321 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 322 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 323 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 324 PARTICULAR PURPOSE. 326 Internet Draft draft-guo-rsvp-te-extensions-00.txt [Page 6]