idnits 2.17.1 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 786. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 815), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 989 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2004) is 7133 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: 'GMPLS-ENNI' is mentioned on line 533, but not defined == Missing Reference: 'GMPLS-ARCH' is mentioned on line 113, but not defined == Missing Reference: 'G.707' is mentioned on line 104, but not defined == Missing Reference: 'G.709' is mentioned on line 104, but not defined == Missing Reference: 'X' is mentioned on line 485, but not defined == Missing Reference: 'L2SC' is mentioned on line 485, but not defined == Missing Reference: 'TDM' is mentioned on line 173, but not defined == Missing Reference: 'LSC' is mentioned on line 173, but not defined == Missing Reference: 'A' is mentioned on line 205, but not defined == Missing Reference: 'B' is mentioned on line 205, but not defined == Missing Reference: 'E' is mentioned on line 205, but not defined == Missing Reference: 'Y' is mentioned on line 221, but not defined == Missing Reference: 'C' is mentioned on line 206, but not defined == Missing Reference: 'CN1' is mentioned on line 220, but not defined == Missing Reference: 'D' is mentioned on line 207, but not defined == Missing Reference: 'CN2' is mentioned on line 220, but not defined == Missing Reference: 'RFC-3473' is mentioned on line 224, but not defined == Missing Reference: 'EGRESS-CONTROL' is mentioned on line 542, but not defined == Missing Reference: 'RFC2207' is mentioned on line 567, but not defined == Missing Reference: 'RFC3097' is mentioned on line 567, but not defined == Unused Reference: 'RFC2961' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 718, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-overlay-04 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- No information found for draft-leroux-mpls-rsvp-rsc-shortage - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SHORT' Summary: 10 errors (**), 0 flaws (~~), 28 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group D. Papadimitriou (Alcatel) 2 Internet Draft D. Brungard (ATT) 3 Expiration Date: April 2005 M. Vigoureux (Alcatel) 4 A. Ayyangar (Juniper) 6 October 2004 8 Generalized MPLS (GMPLS) RSVP-TE Signaling 9 in support of Layer-2 Label Switched Paths (L2 LSP) 11 draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 Most efforts on Generalized MPLS (GMPLS) have been focused on 44 environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.). 45 There is minimal documentation on GMPLS support of Layer-2 Label 46 Switched Paths (L2 LSPs), e.g. native Ethernet LSPs, Asynchronous 47 Transfer Mode (ATM) LSPs and Frame Relay (FR) LSPs. 49 This document details GMPLS capabilities for supporting L2 LSPs in 50 several network environments including overlays. As such, it 51 provides a reference detailing the applicability of GMPLS for Layer- 52 2 switching environments in support of various deployment scenarios, 54 D.Papadimitriou et al. - Expires April 2005 1 55 including the integrated (e.g. multi LSP-region networks), the 56 augmented/peer and the overlay model (e.g. Generalized VPN (GVPN) 57 and user-network interfaces (GMPLS UNI)). 59 1. Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119. 65 In addition the reader is assumed to be familiar with the terms and 66 concepts developed in [RFC3945], [RFC3471], [RFC3473], [RFC3477], 67 and [GMPLS-UNI], [GMPLS-ENNI] as well as [HIER] and [BUNDLE]. 69 The following abbreviations are used in this document: 71 CN: Core node 72 DLCI: Data Link Connection Identifier 73 EN: Edge node 74 ICN: Ingress core node 75 ECN: Egress core node 76 FA: Forwarding Adjacency 77 FR: Frame Relay 78 FSC: Fiber-Switch Capable 79 HOVC: Higher order virtual container 80 ISC: Interface Switching Capability 81 L2-LSP: Layer-2 Label Switched Path 82 L2SC: Layer-2 Switch Capable 83 LOVC: Lower order virtual container 84 LSC: Lambda Switch Capable 85 PSC: Packet Switch Capable 86 OTH: Optical transport hierarchy 87 SDH: Synchronous digital hierarchy. 88 SONET: Synchronous Optical Network. 89 TDM: Time-Division Multiplex 90 VCI: Virtual Channel Identifier 91 VPI: Virtual Path Identifier 93 2. Introduction 95 Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to 96 support four new classes of interfaces Layer-2 Switch Capable (L2SC), 97 Time-Division Multiplex (TDM) capable, Lambda Switch Capable (LSC) 98 and Fiber-Switch Capable (FSC) in addition to Packet Switch Capable 99 (PSC) already supported by MPLS. All these interface classes have 100 been considered in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471]. 102 However, most of the efforts have been concentrated in facilitating 103 the realization of seamless control integration of IP/MPLS networks 104 with SONET/SDH (see [T1.105]/[G.707]) or OTH (see [G.709]) transport 105 networks. The integration of packet and circuit switching 106 technologies under a unified GMPLS control plane provides an 107 homogeneous control management approach for both provisioning 109 D.Papadimitriou et al. - Expires April 2005 2 110 resources and recovery techniques (including protection and re- 111 routing). 113 While being introduced in [GMPLS-ARCH], [GMPLS-RTG] and [RFC3471], 114 the GMPLS capability to control L2SC TE links and L2 LSPs has 115 received very little attention. [RFC3471] defines the Ethernet 116 encoding types (i.e. the encoding of the LSP being requested) and 117 Layer-2 as switching capability (i.e. the type of switching to be 118 performed on a particular link). In this document, a L2 LSP is 119 defined as a LSP being established between intermediate L2SC 120 interfaces. These interfaces are defined as being capable of 121 recognizing frame/cell boundaries and can switch data based on the 122 content of the frame/cell header (example: interfaces on Ethernet 123 switches that switch data based on the content of the MAC header). 125 The motivation for considering GMPLS control of L2 LSPs can be 126 summarized as follows: 127 - it automates the provisioning of transparent LAN services. Today, 128 the delivery of such services can not be automated due to the 129 control plane/topology driven nature of GMPLS that precludes the 130 automated triggering of the server layer LSP from an incoming data 131 flow. 132 - it facilitates the transport of Ethernet flows without introducing 133 additional intermediate packet layer LSPs that require themselves 134 pre-provisioning actions as network trunks that can not be 135 triggered from external traffic demands. 136 - it delivers control plane driven recovery capabilities for 137 a range of technologies (e.g. Ethernet) making classically usage 138 of mechanisms adapted only for environments where these data plane 139 technologies had been initially introduced. For instance, Ethernet 140 Spanning Tree Protocol is less suitable in meshed environments 141 where control plane driven fast recovery is required and available 142 - it simplifies the carrier network operations by avoiding dedicated 143 control protocols for managing Ethernet environments that are not 144 adapted for large scale environments and for which an IP-based 145 protocol counter-part exists (e.g. OSPF). 146 - the use of an IP based addressing scheme elevates the scaling 147 issues generated by the non-hierarchical MAC addressing scheme. 148 This capability allows constructing large scale networks taking 149 advantage of the IP addressing properties (at the control plane 150 level). 151 - it delivers an homogeneous set of signaling mechanisms for 152 controlling L2 technologies for which integration in common 153 infrastructure is made difficult due to their particularities 154 (e.g. ATM and FR). 156 3. Context 158 The reference network considered (but not restricted to) in this 159 document is provided in [GMPLS-UNI], [GMPLS-ENNI] and [RFC3473]. 161 3.1 GMPLS UNI 163 D.Papadimitriou et al. - Expires April 2005 3 164 This network is constituted by a core network including core-nodes 165 (CN) surrounded by edge nodes (EN) that form the overlay networks. In 166 addition, the present document assumes the Traffic Engineering (TE) 167 links inter-connecting the edge and the core nodes are of type 168 [X,L2SC], where X is any ISC whose switched payload can be carried 169 over L2SC TE links. 171 Within the network, the links interconnecting the core nodes can be 172 either [L2SC,L2SC] or any other technology that can carry Layer-2 173 payload, in particular [TDM,TDM] and [LSC,LSC]. Note also that in the 174 first case, the EN-CN interface defines an LSP region boundary (see 175 [HIER]). In the second case, this boundary may be found within the 176 network. 178 As defined in [HIER], a (data plane) switching layer is mapped to a 179 (control plane) LSP region. Following this approach, TE links have 180 been extended to non adjacent nodes by the introduction of 181 Forwarding Adjacency (FA). Using this concept, a node may (under the 182 control of its local policy configuration) advertise an LSP as a TE 183 link into the same IGP routing instance as the one that induces this 184 LSP. Such a link is referred to as a Forwarding Adjacency (FA) and 185 the corresponding LSP to a Forwarding Adjacency LSP (FA-LSP). Since 186 the advertised entity appears as a TE link, both end-point nodes of 187 the FA-LSP must belong to the same OSPF area/IS-IS level. 188 Afterwards, OSPF/IS-IS floods the link-state information about FAs 189 just as it floods the information about any other TE link. This 190 allows other nodes to use FAs as any other TE links for path 191 computation purposes. 193 3.2 GMPLS E-NNI 195 When two core networks (1 and 2) are interconnected by two core 196 nodes (CN1 and CN2), they define an external network-network 197 interface, as illustrated by the following (simplified) topology: 199 B---C F---G 200 / \ / \ 201 --A 1 CN1---CN2 2 H-- 202 \ / \ / 203 E---D J---I 205 In this topology, [A,B], [A,E] and their network 2 counter part are 206 [L2SC,Y] TE links. Then, the first possibility is that [C,CN1], 207 [D,CN1] TE links and their network 2 counter part are [Y,L2SC] TE 208 Links, and [CN1,CN2] is a [L2SC,L2SC] TE link. Therefore, the L2 LSP 209 that can be setup between node A (ingress) and node H (egress) may 210 be constituted by two FA LSPs (the first between A and CN1 and the 211 second between CN2 and H) interconnected by the [L2SC,L2SC] TE link 212 defined at the E-NNI. 214 The other possibility is that the [CN1,CN2] TE link is not a 215 [L2SC,L2SC] TE link. For example, this could be a multi-AS transport 216 scenario where [CN1,CN2] TE link cannot terminate the L2 LSP. In 218 D.Papadimitriou et al. - Expires April 2005 4 219 this case, CN1 and CN2 would only be transporting the L2 LSP from A 220 to H on top of some other LSP. So, the TE link between [CN1,CN2] 221 would then have to be [Y,Y] in which case there would be a single 222 FA-LSP from A to H. 224 Applicability of GMPLS RSVP-TE signaling [RFC-3473] at the E-NNI is 225 detailed in [GMPLS-ENNI]. 227 3.3 GMPLS Signaling Channel 229 For nodes inter-connected by point-to-point native L2 interfaces, the 230 signaling channel may be out-of-band or in-band. In the latter case, 231 several implementation choices are possible for the GMPLS signaling 232 channel: 1) specific Ethertype that allows discrimination between 233 data and control traffic (that may be directed towards a dedicated 234 destination MAC address), 2) dedicated VLAN ID, VPI/VCI (see 235 [RFC3035], Section 7) or DLCI (see [RFC3034], Section 6) for the 236 control traffic, and 3) use of a dedicated destination MAC address 237 for reaching the peering GMPLS controller. Nevertheless, the 238 signaling transport implementation MUST be strictly independent of 239 the signaling transport mechanism used between peering GMPLS nodes. 241 4. Addressing 243 Addressing follows the rules defined in [GMPLS-UNI] and [GMPLS- 244 ENNI]. The SESSION and SENDER_TEMPLATE/FILTER_SPEC objects are end- 245 to-end significant i.e. a single end-to-end RSVP session is defined 246 (in compliance with the RSVP paradigm). 248 5. Signaling 250 L2 LSP setup, notification, graceful and non-graceful deletion 251 procedures follow [RFC3471], [RFC3473] including Graceful Restart 252 upon control channel and node failure, [GMPLS-UNI] and [GMPLS-ENNI]. 253 Signaling mechanisms applies to both uni- and bi-directional L2 LSP. 255 Translation of the L2 LSP request at the edge CN can make use of one 256 of the following method: 1) direct end-to-end LSP [RFC3473], 2) LSP 257 splicing i.e. the tail-end of the incoming LSP is attached to the 258 head-end of the outgoing LSP (see [RFC3471]) and stitching, 3) LSP 259 nesting into a FA-LSP [HIER]. Note that techniques for automated LSP 260 stitching are described in [MPLS-IRN]. 262 Also, in the overlay context, L2 LSPs nesting into a FA-LSP can be 263 used when the ingress/egress edge CN provides (flow) multiplexing 264 capabilities. 266 5.1 L2 Generalized Label Request 268 The Generalized Label Request is defined in [RFC3471], Section 3.1. 269 The different LSP Encoding Type and Switching Type (of the 270 GENERALIZED_LABEL REQUEST object) that can be used for requesting L2 271 LSP label is detailed in Table 1. 273 D.Papadimitriou et al. - Expires April 2005 5 274 Value LSP Encoding type Value Switching Type 275 ----- ----------------- ----- -------- 276 2 Ethernet 51 L2SC 277 14 (new) ATM 51 L2SC 278 15 (new) Frame-Relay 51 L2SC 280 Table 1: LSP Encoding Type and Switching Type code-points 281 for Ethernet, ATM and FR LSPs 283 For the Generalized PID (G-PID) that identifies the payload carried 284 by an LSP, standard Ethertype values are used for Ethernet LSPs. 286 5.2 L2 SENDER_TSPEC and FLOWSPEC 288 New L2 SENDER_TSPEC and FLOWSPEC objects are introduced to describe 289 bandwidth and delay/jitter characteristics for the L2 LSP as well as 290 any such L2 traffic specific characteristics. 292 As per [RFC3471], GMPLS allows the inclusion of technology specific 293 parameters in signaling. The intent is for all technology specific 294 parameters to be carried, when using RSVP-TE, in the SENDER_TSPEC 295 and other related objects. So new L2 SENDER_TSPEC and FLOWSPEC 296 objects are defined as follows. These traffic parameters MUST be 297 used when L2SC is specified in the LSP Switching Type field of a 298 Generalized Label Request (see [RFC3471]) and the LSP encoding type 299 is Ethernet, ATM or Frame-Relay. 301 5.2.1 L2 SENDER_TSPEC object 303 The L2 SENDER_TSPEC object (Class-Num = 12, Class-Type = 6) has the 304 following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Length | Class-Num (12)| C-Type (6) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Switching Granularity | MTU | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | | 314 ~ TLVs ~ 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Switching Granularity (SG): 16 bits 320 This field indicates the type of L2 link that comprises the 321 requested LSP. 323 The permitted L2 Link Type values: 325 Value Switching Granularity 327 D.Papadimitriou et al. - Expires April 2005 6 328 ----- ------------------------ 329 1 Ethernet Port 330 2 Ethernet VLAN 331 3 ATM Port 332 4 ATM VP Bundle 333 5 ATM VP 334 6 ATM VC 335 7 Frame Relay Port 336 8 Frame Relay DLCI 338 Value 0 is reserved. Values 128 through 255 are reserved for 339 vendor specific usage. 341 MTU: 16 bits 343 This is a two-octet value indicating the MTU in octets. 345 Note: the notion of MTU does not apply to ATM LSPs (fixed cell 346 size of 53 bytes) and MUST thus be set to 53. 348 TLV: 350 The L2 SENDER_TSPEC object MUST include at least one (i.e. the 351 Type 1 TLV) and MAY include more than one optional TLV (for 352 which the Type is > 1). Type 1 TLV MAY appear at most once 353 per SENDER_TSPEC object. 355 Each TLV has the following format: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 ~ Value ~ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Length: 16 bits 369 Indicates the total length of the TLV, i.e., 4 + the length of 370 the value field in octets. A value field whose length is not 371 a multiple of four MUST be zero-padded so that the TLV is 372 four-octet aligned. 374 Type: 16 bits 376 Defined values are: 378 Type Length Format Description 379 -------------------------------------------------- 380 1 20 See below L2_QoS 382 D.Papadimitriou et al. - Expires April 2005 7 383 Types 128 through 255 are reserved for vendor specific TLVs. 384 Additional L2 technology specific TLVs MAY be defined in 385 future revision of this document. 387 Type 1 TLV (L2 QoS) Indicates the QoS type of the traffic. 388 This TLV has the following format: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Service Class | Reserved | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Bandwidth (32-bit IEEE floating point number) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Jitter (microseconds) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Delay (microseconds) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Service Class: 8 bits 404 Identifies the service class i.e. the tuples that can be constructed using this TLV. Default 406 value is 0x0001. Value range 0x0000 to 0x0008 is reserved as 407 part of this document. 409 Reserved: 24 bits 411 These bits SHOULD be set to zero when sent and MUST be ignored 412 when received. 414 Bandwidth: 32 bits 416 The requested bandwidth for the L2 LSP. The unit is bytes per 417 second. For instance, a 1Gbps Ethernet LSP will have a value 418 of 0x4CEE6B28. 420 Jitter: 32 bits 422 Indicates the maximum acceptable jitter (in microseconds) for 423 this LSP. If unspecified, this value is set to 0x00000000. 425 Delay: 32 bits 427 Indicates the maximum acceptable delay (in microseconds) for 428 this LSP. If unspecified, this value is set to 0x00000000. 430 5.2.2 L2 FLOWSPEC object 432 The L2 FLOWSPEC object (Class-Num = 12, Class-Type = 6) has the same 433 format as the L2 SENDER_TSPEC object. 435 D.Papadimitriou et al. - Expires April 2005 8 436 5.2.3 Processing 438 The L2 SENDER_TSPEC object carries the traffic specification 439 generated by RSVP session sender. The L2 SENDER_TSPEC object SHOULD 440 be forwarded and delivered unchanged to both intermediate and egress 441 nodes. The L2 FLOWSPEC object carries reservation request 442 information generated by receivers. As any FLOWSPEC object, the 443 information content of the L2 FLOWSPEC object flows upstream towards 444 ingress node. 446 For a particular sender in a RSVP session the contents of the 447 FLOWSPEC object received in a Resv message SHOULD be identical to 448 the contents of the SENDER_TSPEC object sent in the corresponding 449 Path message. If the objects do not match, a ResvErr message with a 450 "Traffic Control Error/Bad Flowspec value" error SHOULD be 451 generated. 453 Intermediate and egress nodes MUST verify that the node itself and 454 the interfaces on which the LSP will be established can support the 455 requested Switching Granularity, MTU and values included in sub- 456 object TLVs. If the requested value(s) can not be supported, the 457 receiver node MUST generate a PathErr message with a "Traffic 458 Control Error/Service unsupported" indication (see [RFC2205]). 460 In addition, if the MTU field is received with a value smaller than 461 the minimum transfer unit size of the L2 specific technology (e.g. 462 46 bytes for Ethernet, 38 bytes for IEEE 802.3), the node MUST 463 generate a PathErr message with a "Traffic Control Error/ Bad Tspec 464 value" indication (see [RFC2205]). 466 There is no specific Adspec associated with the L2 SENDER_TSPEC. 467 Either the Adspec is omitted or an Int-serv Adspec with the Default 468 General Characterization Parameters and Guaranteed Service fragment 469 is used, see [RFC2210]. 471 5.3 L2 Label 473 L2 LABEL object follows the generic rules of the GENERALIZED_LABEL 474 object (Class-Num = 16) defined in [RFC3471] for the C-Type 2. This 475 is a 32-bit label value that allows the sending and receiving node 476 performing the link local operations for the requested L2 LSP. 478 The interpretation of the received label depends on the type of the 479 link over which the label is used. The received label MUST be 480 interpreted according the requestor traffic parameters, i.e. a label 481 by itself does not allow knowing the detailed properties of the L2 482 LSP being requested (i.e. L2 labels are context sensitive). 484 Table 2 summarizes the L2 labels representation (that can be 485 supported over [X,L2SC], [L2SC,L2SC] and [L2SC,X] TE links) and 486 assigned upon reception of the LSP Encoding and Switching Types: 488 LSP Encoding type Switching Type Label 490 D.Papadimitriou et al. - Expires April 2005 9 491 ----------------- -------------- ----------------------------- 492 Ethernet L2SC Port, VLAN ID 493 ATM L2SC Port, VPI, VCI, VP Bundle ID 494 Frame-Relay L2SC Port, DLCI 496 Table 2. L2 Labels 498 Ethernet Port, ATM Port and Frame Relay Port labels are encoded 499 right justified aligned in 32 bits (4 octets). Ethernet VLAN ID 500 labels are encoded with the VLAN ID value (12 bits) right justified 501 in bits 20-31 (and preceding bits must be set to 0). ATM VPI/VCI 502 labels are encoded per [RFC3036] Section 3.4.2.2. Frame-Relay DLCI 503 label values are encoded per [RFC3036] Section 3.4.2.3. Note that 504 the VLAN label space should be applicable on per port basis, 505 otherwise the number of LSP per node is limited to 4096. This 506 applies also most likely to ATM and FR nodes. 508 Bi-directional L2 LSPs are indicated by the presence of an upstream 509 label in the Path message. Upstream label assignment follows the 510 format of the UPSTREAM LABEL object and the procedures defined in 511 [RFC3473]. 513 5.4 Interface Identification 515 Interface identification follows the rules defined in [RFC3473], 516 Section 8.1 and [RFC3477]. 518 6. Explicit Routing 520 6.1 EXPLICIT_ROUTE Object (ERO) Processing 522 EXPLICIT ROUTE objects can make use of the subobjects defined in 523 [RFC3209] for numbered TE links, [RFC3477] for unnumbered TE links 524 and finally [RFC3473] for labels. EXPLICIT ROUTE objects processing 525 MUST follow the procedures defined in [RFC3209], [RFC3473], 526 [RFC3477], and [GMPLS-UNI] and [GMPLS-ENNI] when applicable. 528 6.2 RECORD_ROUTE Object (RRO) Processing 530 RECORD ROUTE objects can make use of the subobjects defined in 531 [RFC3209] for numbered TE links and labels, [RFC3477] for unnumbered 532 TE links. RECORD ROUTE objects processing MUST follow the procedures 533 defined in [RFC3209], [RFC3473], [RFC3477], and [GMPLS-UNI], [GMPLS- 534 ENNI] when applicable. 536 6.3 Explicit Label Control 538 Explicit label control refers to the label identification of the 539 egress TE link. An ingress node may include an ERO for which the 540 last hop includes the node_ID of the egress node and any other sub- 541 objects necessary to uniquely identify the TE link, component link 542 and labels for the requested Ethernet LSP. See [EGRESS-CONTROL] for 543 procedural details. 545 D.Papadimitriou et al. - Expires April 2005 10 546 Note: in the overlay context, when the L-bit is set, this last-hop 547 may be the only hop included in the ERO (see [GMPLS-UNI]). 549 7. Security considerations 551 The introduction of layer-2 label switched path, particularly in 552 Ethernet networks may raise some security issues that need to be 553 solved. 555 The solution MUST protect against the traditional following security 556 threats: 558 - Possibility for the network to control the traffic injected by the 559 client in the data plane (BPDU, Multicast, Broadcasts, etc.) or 560 the control plane (using RSVP-TE signaling for setting-up or 561 tearing down the L2 LSPs) 562 - All usual threats brought by IP functionalities (control and data 563 plane) 564 - Entry points induced by the possible coexistence of the two 565 technologies (L2LSPs and usual Broadcast Ethernet mode) 567 Current RSVP security mechanisms [RFC2207], [RFC3097] should also be 568 analyzed/evaluated in the context of L2 LSPs. 570 7.1 Attacks on the Data Plane 572 This category encompasses attacks on the Data Plane. Attacks on the 573 data plane can be of the following form: 574 - modification of data traffic 575 - insertion of non-authentic data traffic 576 - Denial of Service (DoS) attacks 577 - traffic snooping 579 Introduction of L2 LSP signaling MUST prevent these attacks by 580 offering adequate filters (like ACLs or some new means). 582 L2 LSP SHOULD reduce data plane threats, as the number of network 583 entry points to control is reduced. A L2 LSP is by nature a hermetic 584 tunnel, with a single entry point (head-end LSR). Policing and 585 filtering is required only on the head-end LSR. 587 Moreover, some mechanism MUST be provided at the network edges (on 588 the head-end LSRs), in order to rate limit the amount of traffic 589 that can transit into a given L2 LSP. 591 7.2 Attacks on the Control Plane 593 There are two threats concerning the control plane. The first one 594 corresponds to the potential initiation of the signaling by the 595 client side. As LSP tunnels MAY be signaled from the client site 596 using RSVP-TE, control of such activity MUST be provided so that it 598 D.Papadimitriou et al. - Expires April 2005 11 599 cannot be used to fail the entire network. Note that this applies 600 generally to any client signaling approach. 602 There MUST be a way to limit, by configuration, the number of TE- 603 LSPs that can be signaled by a particular client, also there must be 604 a way to rate limit RSVP client control plane traffic (mainly 605 refresh interval). 607 Also the operator MUST be able to rate limit, by configuration, the 608 total amount of memory and CPU allocated to the RSVP process on a 609 given LSR, and react appropriately when such bound is reached (see 610 [SHORT]) 612 Another threat with regards to the Control Plane comes from the 613 introduction of IP functions in L2 equipments (such as the handling 614 of multicast and so on). Indeed L2 networks will inherit all 615 security issue of IP networks. 617 7.3 Security problems induced by the migration 619 If both L2 LSPs and classical Ethernet are used on the same network, 620 then different ranges of VLANs must be considered so that different 621 traffics, with different VLAN semantics do not get mixed for 622 example. 624 8. IANA Considerations 626 Two values have to be defined by IANA for this document. 628 Two RSVP C-Types in registry: 630 http://www.iana.org/assignments/rsvp-parameters 632 - L2 SENDER_TSPEC object: Class = 12, C-Type = 6 (Suggested value) 634 - L2 FLOWSPEC object: Class = 9, C-Type = 6 (Suggested value) 636 IANA is also requested to track the code-point spaces extended 637 and/or updated by this document. That is: 638 - LSP Encoding Type 639 - Generalized PID (G-PID) 641 9. Acknowledgments 643 The authors would like to acknowledge Emmanuel Dotaro for the 644 fruitful discussions and Mastuura Nobuaki for his useful comments to 645 this document. 647 The author would like to thank Jean-Louis Leroux, Simon Delord and 648 Romain Insler for their contribution on the security section. 650 10. References 652 D.Papadimitriou et al. - Expires April 2005 12 653 10.1 Normative References 655 [BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic 656 Engineering", Internet Draft, Work in Progress, draft- 657 ietf-mpls-bundle-04.txt, July 2002. 659 [GMPLS-ENNI]D.Papadimitriou et al., "Generalized MPLS (GMPLS) RSVP- 660 TE Signalling in support of Automatically Switched 661 Optical Network (ASON)." Internet Draft, Work in 662 progress, draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, 663 July 2004. 665 [GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the 666 Overlay Model", Internet Draft, Work in Progress, draft- 667 ietf-ccamp-gmpls-overlay-04.txt, April 2004. 669 [GMPLS-RTG] K.Kompella and Y.Rekhter (Editors) et al., "Routing 670 Extensions in Support of Generalized MPLS", Internet 671 Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing- 672 09.txt, October 2003. 674 [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with 675 Generalized MPLS TE", Internet Draft, Work in Progress, 676 draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. 678 [RFC2205] R.Braden (Editor) et al., "Resource ReserVation 679 Protocol -- Version 1 Functional Specification", RFC 680 2205, September 1997. 682 [RFC2210] J.Wroclawski, "The Use of RSVP with IETF Integrated 683 Services", RFC 2210, September 1997. 685 [RFC2961] L.Berger et al., "RSVP Refresh Overhead Reduction 686 Extensions", RFC 2961, April 2001. 688 [RFC3034] A.Conta et al., "Use of Label Switching on Frame Relay 689 Networks Specification", RFC 3034, January 2001. 691 [RFC3035] B.Davie et al., "MPLS using LDP and ATM VC Switching", 692 RFC 3035, January 2001. 694 [RFC3036] L.Andersson et al., "LDP Specification", RFC 3036, 695 January 2001. 697 [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 698 LSP Tunnels", RFC 3209, December 2001. 700 [RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol 701 Label Switching (GMPLS) - Signaling Functional 702 Description", RFC 3471, January 2003. 704 D.Papadimitriou et al. - Expires April 2005 13 706 [RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol 707 Label Switching (GMPLS) Signaling Resource ReserVation 708 Protocol-Traffic Engineering (RSVP-TE) Extensions", 709 RFC 3473, January 2003. 711 [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered 712 Links in Resource ReserVation Protocol-Traffic 713 Engineering (RSVP-TE)", RFC 3477, January 2003. 715 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 716 RFC 3667, February 2004. 718 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 719 Technology", BCP 79, RFC 3668, February 2004. 721 [RFC3945] E.Mannie (Editor) et al., "Generalized Multi-Protocol 722 Label Switching (GMPLS) Architecture", RFC 3945, 723 October 2004. 725 [SHORT] Le Roux, J.L., Mazeas, J.Y, "Procedure to handle RSVP- 726 TE control resources shortages", Work in progress, 727 draft-leroux-mpls-rsvp-rsc-shortage-00.txt, October 728 2004. 730 10.2 Informative References 732 [MPLS-IRN] A.Ayyangar et al., "Inter-region MPLS Traffic 733 Engineering", Internet Draft, Work in progress, draft- 734 ayyangar-inter-region-te-01.txt, October 2003. 736 11. Author's addresses 738 Dimitri Papadimitriou (Alcatel) 739 Francis Wellensplein 1, 740 B-2018 Antwerpen, Belgium 741 Phone : +32 3 240 8491 742 EMail: dimitri.papadimitriou@alcatel.be 744 Deborah Brungard (AT&T) 745 Rm. D1-3C22 - 200 S. Laurel Ave. 746 Middletown, NJ 07748, USA 747 Phone: +1 732 420 1573 748 EMail: dbrungard@att.com 750 Martin Vigoureux (Alcatel) 751 Route de Nozay, 752 91461 Marcoussis cedex, France 753 Phone: +33 1 6963 1852 754 EMail: martin.vigoureux@alcatel.fr 756 Arthi Ayyangar (Juniper) 757 1194 N.Mathilda Ave 758 Sunnyvale, CA 94089, USA 760 D.Papadimitriou et al. - Expires April 2005 14 761 EMail: arthi@juniper.net 763 D.Papadimitriou et al. - Expires April 2005 15 764 Intellectual Property Statement 766 The IETF takes no position regarding the validity or scope of any 767 Intellectual Property Rights or other rights that might be claimed 768 to pertain to the implementation or use of the technology described 769 in this document or the extent to which any license under such 770 rights might or might not be available; nor does it represent that 771 it has made any independent effort to identify any such rights. 772 Information on the procedures with respect to rights in RFC 773 documents can be found in BCP 78 and BCP 79. 775 Copies of IPR disclosures made to the IETF Secretariat and any 776 assurances of licenses to be made available, or the result of an 777 attempt made to obtain a general license or permission for the use 778 of such proprietary rights by implementers or users of this 779 specification can be obtained from the IETF on-line IPR repository 780 at http://www.ietf.org/ipr. 782 The IETF invites any interested party to bring to its attention any 783 copyrights, patents or patent applications, or other proprietary 784 rights that may cover technology that may be required to implement 785 this standard. Please address the information to the IETF at 786 ietf-ipr@ietf.org. 788 Disclaimer of Validity 790 This document and the information contained herein are provided on 791 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 792 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 793 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 794 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 795 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 798 Copyright Statement 800 Copyright (C) The Internet Society (2004). This document is subject 801 to the rights, licenses and restrictions contained in BCP 78, and 802 except as set forth therein, the authors retain all their rights. 804 Acknowledgment 806 Funding for the RFC Editor function is currently provided by the 807 Internet Society. 809 D.Papadimitriou et al. - Expires April 2005 16 810 12. Full Copyright Statement 812 Copyright (C) The Internet Society (2004). This document is 813 subject to the rights, licenses and restrictions contained in BCP 814 78, and except as set forth therein, the authors retain all their 815 rights. 817 This document and the information contained herein are provided 818 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 819 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 820 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 821 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 822 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 823 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 824 PARTICULAR PURPOSE. 826 D.Papadimitriou et al. - Expires April 2005 17