idnits 2.17.1 draft-cai-vc-rsvp-te-00.txt: 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 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. 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.) -- The document date (February 2001) is 8464 days in the past. Is this intentional? 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 section? '5' on line 244 looks like a reference -- Missing reference section? '2' on line 277 looks like a reference -- Missing reference section? '3' on line 59 looks like a reference -- Missing reference section? '1' on line 71 looks like a reference -- Missing reference section? 'Note' on line 193 looks like a reference -- Missing reference section? '4' on line 369 looks like a reference -- Missing reference section? '8' on line 236 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Martin Machacek 3 Document: draft-cai-vc-rsvp-te-00.txt Ting Cai 4 Expires: August 2001 Terabeam Networks, Inc. 5 February 2001 7 Signaling Virtual Circuit Label Using RSVP-TE 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document proposes an extension to RSVP-TE to distribute VC 32 labels required by L2 circuit over MPLS encapsulation proposed by 33 Martini et. al. The distribution of VC labels is piggybacked on 34 signaling of LSP tunnels using two new RSVP objects. 36 Table of Contents 38 Status of this Memo................................................1 39 Abstract...........................................................1 40 Conventions used in this document..................................2 41 VC LABEL Object....................................................2 42 VC LABEL REQUEST Object............................................4 43 Processing Rules...................................................6 44 Security Considerations............................................7 45 Acknowledgements...................................................8 46 References.........................................................9 47 Author's Addresses.................................................9 48 Signaling Virtual Circuit Label Using RSVP-TE February 2001 50 Introduction 52 Martini et. al. proposed in [5] a method of encapsulating L2 PDUs in 53 MPLS packets. The method uses a stack of two labels: one specifying 54 the LSP tunnel across the MPLS network and the other identifying the 55 virtual circuit (VC) to which the L2 PDUs belong. Martini et. al. 56 proposed a method for distributing VC labels using LDP in 57 downstream-unsolicited mode in [2]. 59 We propose a simple extension to RSVP-TE [3] to signal VC labels 60 using RSVP-TE in downstream-on-demand mode. The extension includes 61 two new RSVP object classes, VC LABEL and VC LABEL REQUEST. The 62 data formats including their interpretations are taken from [2] with 63 only minor modifications required by the RSVP object format. This 64 should simplify implementations supporting both LDP and RSVP-TE. 66 Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 70 this document are to be interpreted as described in RFC-2119 [1]. 72 VC LABEL Object 74 The VC LABEL object MAY be used in RSVP RESV messages when replying 75 to RSVP PATH messages with VC LABEL REQUEST object. The VC LABEL 76 object SHOULD only be interpreted by the originator of the VC LABEL 77 REQUEST object at the ingress of the tunnel. Multiple VC LABEL 78 objects MAY be present in one RESV message. If multiple VC LABEL 79 objects with identical VC ID are present, the first object MUST be 80 used while others MUST be ignored and notification to management 81 SHOULD be generated. 83 The VC LABEL Class number is 208 [Note] and currently only C-Type 1 84 is defined. The VC LABEL class is optional from RSVP point of view. 85 Based on rules in Section 3.10 of [4] all label switch routers (LSR) 86 that do not support this class MUST ignore the object and pass it 87 unchanged. LSRs supporting the VC Label Request class MUST also 88 support VC Label class. 90 The VC LABEL object has the following format: 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Reserved |C| VC Type |VC info Length | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Group ID | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | VC ID | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Interface parameters | 102 | " | 103 Signaling Virtual Circuit Label Using RSVP-TE February 2001 105 | " | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | VC LABEL | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Reserved 112 MUST be set to zero on transmission and ignored on receipt. 114 VC TYPE 116 A 15-bit quantity containing a value that represents the type 117 of VC. Assigned values are: 119 VC Type Description 121 0x0001 Frame Relay DLCI 122 0x0002 ATM AAL5 VCC transport 123 0x0003 ATM transparent cell transport 124 0x0004 Ethernet VLAN 125 0x0005 Ethernet 126 0x0006 HDLC ( Cisco ) 127 0x0007 PPP 128 0x8008 CEM [8] 129 0x0009 ATM VCC cell transport 130 0x000A ATM VPC cell transport 131 0x000B MPLS 133 Control word bit (C) 135 The C bit is used to signal whether control word (as defined in 136 [5]) will be used for the VC. 138 C bit = 1 control word present on this VC. 139 C bit = 0 no control word present on this VC. 141 VC information length 143 Length of the VC ID field and the interface parameters field in 144 octets. If this value is 0, then it references all VCs using 145 the specified group ID and there is no VC ID present, nor any 146 interface parameters. The length must be multiple of 4. 148 Group ID 150 An arbitrary 32 bit value which represents a group of VCs that 151 is used to augment the VC space. This value MUST be user 152 configurable. The group ID is intended to be used as a port 153 index, or a virtual tunnel index. To simplify configuration a 154 particular VC ID at ingress could be part of the virtual tunnel 155 for transport to the egress router. The Group ID can be used 156 to send a wild card label withdrawals to remote LSRs upon 157 physical port failure. 159 Signaling Virtual Circuit Label Using RSVP-TE February 2001 161 VC ID 163 A non-zero 32-bit connection ID that together with the VC type, 164 identifying VC for which label is being provided. 166 Interface parameters 168 A variable length field that is used to provide interface 169 specific parameters of the egress interface of the VC. Format 170 of this field is described in section 5.1 of [2]. Interface 171 parameter field MAY be present even if no special parameters 172 were requested in the corresponding LABEL REQUEST object. Total 173 length of this field MUST be multiple of 4 and if necessary it 174 MUST be padded with zeroes to the nearest 32-bit boundary. 176 VC LABEL 178 Generic MPLS label encoded right aligned in 4 octets. Note that 179 ATM and Frame Relay labels cannot be used in this context. 181 VC LABEL REQUEST Object 183 The VC LABEL REQUEST object MAY be used in RSVP PATH messages to 184 request label mapping for a particular VC from the egress LSR. The 185 VC LABEL REQUEST object SHOULD be interpreted only by the egress LSR 186 whose router ID is the tunnel end point IP address in the Session 187 object of the RSVP PATH message. Multiple VC LABEL REQUEST objects 188 MAY be present in one PATH message. If multiple LABEL REQUEST 189 objects with identical VC ID are present only the first one MUST be 190 used while others MUST be ignored and notification to management 191 SHOULD be generated. 193 The VC LABEL REQUEST class number is 209 [Note] and currently only 194 C-Type 1 is defined. The VC LABEL REQUEST object is optional from 195 RSVP point of view. Based on rules in Section 3.10 of [4] all LSRs 196 that do not support this class MUST ignore it and pass it unchanged. 197 LSRs supporting VC LABEL REQUEST class MUST also support VC LABEL 198 class. 200 The VC LABEL REQUEST object has following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved |C| VC TYPE |VC Info Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Group ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | VC ID | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Interface Parameters | 212 | " | 213 Signaling Virtual Circuit Label Using RSVP-TE February 2001 215 | " | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Reserved 220 MUST be zeroed on transmission and ignored on receipt. 222 VC TYPE 224 A 15-bit quantity containing a value which represents the type 225 of VC. Assigned Values are: 227 VC Type Description 229 0x0001 Frame Relay DLCI 230 0x0002 ATM AAL5 VCC transport 231 0x0003 ATM transparent cell transport 232 0x0004 Ethernet VLAN 233 0x0005 Ethernet 234 0x0006 HDLC ( Cisco ) 235 0x0007 PPP 236 0x8008 CEM [8] 237 0x0009 ATM VCC cell transport 238 0x000A ATM VPC cell transport 239 0x000B MPLS 241 Control word bit (C) 243 The C bit is used to signal whether control word (as defined in 244 [5]) will be used for the VC. 246 C bit = 1 control word present on this VC. 247 C bit = 0 no control word present on this VC. 249 VC information length 251 Length of the VC ID field and the interface parameters field in 252 octets. If this value is 0, then it references all VCs using 253 the specified group ID and there is no VC ID present, nor any 254 interface parameters. The length must be multiple of 4. 256 Group ID 258 An arbitrary 32 bit value which represents a group of VCs that 259 is used to augment the VC space. This value MUST be user 260 configurable. The group ID is intended to be used as a port 261 index, or a virtual tunnel index. To simplify configuration a 262 particular VC ID at ingress could be part of the virtual tunnel 263 for transport to the egress router. The Group ID is very useful 264 to send a wild card label withdrawals to remote LSRs upon 265 physical port failure. 267 VC ID 268 Signaling Virtual Circuit Label Using RSVP-TE February 2001 270 A non-zero 32-bit connection ID that together with the VC type, 271 identifying VC for which label is being provided. 273 Interface parameters 275 Variable length field is used to provide interface specific 276 parameters of the ingress interface of the VC. Format of this 277 field is described in section 5.1 of [2]. Interface parameter 278 field MAY be present even if no special parameters were 279 requested in corresponding LABEL REQUEST object. Total length 280 of this field MUST be multiple of 4 and if necessary it MUST be 281 padded with zeroes to the nearest 32-bit boundary. 283 Processing Rules 285 Ingress 287 To request VC label for a particular virtual circuit, the 288 ingress of L2 tunnel places VC LABEL REQUEST objects with 289 appropriate VC Type in RSVP PATH messages and sends them to the 290 egress. VC Label Request objects SHOULD be placed immediately 291 after LABEL REQUEST objects in the PATH message. The ingress 292 node SHOULD set the C bit in the VC LABEL REQUEST object if it 293 intends to use the control word in the encapsulation of L2 294 PDUs. The ingress node MUST NOT send data over the L2 circuit 295 if: 297 - the egress node does not reply with VC LABEL object 298 - the VC LABEL object has C bit set and the LSR is 299 not capable of supporting control word in the 300 encapsulation. 301 - interface parameters specified in the VC LABEL object 302 are not acceptable, 303 - interface parameters specified in VC LABEL REQUEST 304 object was not found in corresponding VC LABEL object. 306 Ingress node SHOULD stop sending VC LABEL REQUEST objects in 307 RSVP PATH messages if it detects that the egress node of the 308 L2 channel is not operational. 310 If ingress does not receive RESV replies with VC LABEL objects 311 from the egress after certain timeout period, it SHOULD use 312 methods appropriate in the L2 protocol to signal that the 313 receiving side of the virtual circuit is not operational. The 314 signal SHOULD be sent to the L2 link that is being tunneled 315 over MPLS network. 317 If ingress wants to change the VC setup, it simply sends 318 revised VC LABEL REQUEST objects in PATH messages. The virtual 319 circuit that does not have corresponding VC ID in the revised 320 VC LABEL REQUEST object SHOULD be torn down. 322 Signaling Virtual Circuit Label Using RSVP-TE February 2001 324 If ingress wants to tear down a particular virtual circuit it 325 SHOULD stop sending VC Label Request object in PATH messages. 326 Alternatively it MAY also initiate the teardown procedure as 327 defined in [4]. 329 Egress 331 The egress node replies to VC LABEL REQUEST objects in PATH 332 messages with VC LABEL objects in RESV messages. The egress 333 node MUST NOT reply with LABEL object if: 335 - the VC Type specified in the VC Label Request is not 336 supported, 337 - the specified VC ID does not match any configured 338 virtual circuit 339 - the VC Label Request object has the C bit set and 340 the egress LSR is not capable of using control word 341 in L2 PDU encapsulation. 342 - interface parameters specified in the VC LABEL 343 REQUEST object are not acceptable. 344 - the receiving side of the L2 circuit related to the 345 VC ID is not operational. 347 The egress node MAY set the C bit to 1 in VC Label object if it 348 requires the ingress node to use the control word in the 349 encapsulation. This may occur even if the VC Label Request 350 object that has C bit set to zero. If interface parameter field 351 is included in the VC LABEL REQUEST, egress LSR MUST include 352 this field unchanged in the VC LABEL object. It MAY include 353 interface parameter field in the VC LABEL object even if no 354 such field was present in the corresponding VC LABEL REQUEST. 356 If egress does not receive PATH messages with VC LABEL REQUEST 357 objects after certain timeout period, it SHOULD use methods 358 appropriate for the L2 protocol to signal that the sending side 359 of the virtual circuit is not operational. The signal should 360 be sent on the L2 link that is being tunneled over MPLS 361 network. 363 If egress wants to change the VC setup, it simply sends revised 364 VC LABEL objects in RESV messages. 366 If egress wants to tear down a particular VC of L2 it SHOULD 367 stop replying to the corresponding VC Label Requests. 368 Alternatively it MAY also initiate the teardown procedure as 369 defined [4]. 371 Security Considerations 373 This document does not affect the underlying security issues of 374 MPLS. 376 Signaling Virtual Circuit Label Using RSVP-TE February 2001 378 Acknowledgements 380 We would like to thank Jeff Apple for reviewing the draft and Steve 381 Cheek and Karel Zikan for their just-in-time help on editing the 382 draft. 384 Signaling Virtual Circuit Label Using RSVP-TE February 2001 386 References 388 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 389 Levels", BCP 14, RFC 2119, March 1997 391 2 "Transport of Layer 2 Frames Over MPLS", draft-martini- 392 l2circuit-trans-mpls-04.txt, Work in Progress. 394 3 "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp- 395 lsp-tunnel-07.txt, Work in Progress. 397 4 RFC 2205 R. Branden, L.Zhang, S. Berson, S. Herzog, S. Jamin, 398 "Resource Reservation Protococol (RSVP) -- Version 1 Functional 399 Specification", September, 1997 401 5 "Encapsulation Methods for Transport of Layer 2 Frames Over 402 MPLS", draft-martini-l2circuit-encap-mpls-01.txt, Work in Progress 404 Note: The RSVP class number 208 and 209 and their C-Types is pending 405 IANA approval. 407 Author's Addresses 409 Martin Machacek 410 Terabeam Networks, Inc. 411 14833 NE 87th St. Phone: 412 Redmond, WA, USA Email: Martin.Machacek@Terabeam.com 414 Ting Cai 415 Terabeam Networks, Inc. 416 14833 NE 87th St. Phone: (206) 321-6367 417 Redmond, WA, USA Email: Ting.Cai@terabeam.com