idnits 2.17.1 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 751. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 780), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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. 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 15 longer pages, the longest (page 2) being 59 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.) 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 (June 2005) is 6889 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: 'G.707' is mentioned on line 96, but not defined == Missing Reference: 'G.709' is mentioned on line 96, but not defined == Missing Reference: 'RFC3032' is mentioned on line 120, but not defined == Missing Reference: 'RFC3916' is mentioned on line 121, but not defined == Missing Reference: 'X' is mentioned on line 374, but not defined == Missing Reference: 'L2SC' is mentioned on line 397, but not defined == Missing Reference: 'A' is mentioned on line 390, but not defined == Missing Reference: 'B' is mentioned on line 390, but not defined == Missing Reference: 'E' is mentioned on line 390, but not defined == Missing Reference: 'Y' is mentioned on line 401, but not defined == Missing Reference: 'G' is mentioned on line 391, but not defined == Missing Reference: 'H' is mentioned on line 391, but not defined == Missing Reference: 'I' is mentioned on line 391, but not defined == Missing Reference: 'C' is mentioned on line 392, but not defined == Missing Reference: 'CN1' is mentioned on line 401, but not defined == Missing Reference: 'D' is mentioned on line 392, but not defined == Missing Reference: 'CN2' is mentioned on line 401, but not defined == Missing Reference: 'F' is mentioned on line 392, but not defined == Missing Reference: 'J' is mentioned on line 393, but not defined == Missing Reference: 'RSVP-ID' is mentioned on line 489, but not defined == Missing Reference: 'RFC4003' is mentioned on line 535, but not defined == Missing Reference: 'RFC2207' is mentioned on line 582, but not defined == Missing Reference: 'RFC3097' is mentioned on line 582, but not defined == Unused Reference: 'RFC2205' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC2961' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC3034' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC3035' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'BUNDLE' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'HIER' is defined on line 708, but no explicit reference was found in the text ** 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) -- Unexpected draft version: The latest known version of draft-ietf-ccamp-gmpls-overlay is -05, but you're referring to -06. == Outdated reference: A later version (-06) exists of draft-ietf-isis-igp-p2p-over-lan-05 Summary: 8 errors (**), 0 flaws (~~), 37 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Papadimitriou (Editor) 3 Internet Draft Jaihyung Choi (Editor) 4 Expiration Date: November 2005 6 June 2005 8 A Framework for Generalized MPLS (GMPLS) Ethernet 10 draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 Most efforts on Generalized MPLS (GMPLS) have been focused on 43 environments covering Circuit oriented LSPs (Sonet/SDH, OTH, etc.) 44 and IP/MPLS Packet switched networks. However, there is minimal 45 documentation on GMPLS support of Layer-2 Label Switched Paths (L2 46 LSPs), e.g. native Ethernet LSPs, Asynchronous Transfer Mode (ATM) 47 LSPs and Frame Relay (FR) LSPs. This document provides a framework 48 for GMPLS in support of L2 LSPs in several network environments, in 49 particular, Ethernet. 51 D.Papadimitriou et al. - Expires November 2005 1 52 1. Contributors 54 This document is the result of the CCAMP Working Group GMPLS for 55 Ethernet design team joint effort. The following are the authors 56 that contributed to the present document: 58 Dimitri Papadimitriou (Alcatel, Team Leader and Editor) 59 dimitri.papadimitriou@alcatel.be 60 Jaihyung Cho (ETRI, Co-Editor) 61 jaihyung@etri.re.kr 62 Loa Andersson (Acreo) 63 loa@pi.se 64 Arthi Ayyangar (Juniper) 65 arthi@juniper.net 66 Deborah Brungard (ATT) 67 dbrungard@att.com 68 Simon Delord (France Telecom) 69 simon.delord@francetelecom.com 70 Avri Doria (ETRI) 71 avri@psg.com 72 Anders Gavler (Acreo) 73 anders.gavler@acreo.se 74 Jean-Louis Le Roux (France Telecom) 75 jeanlouis.leroux@francetelecom.com 76 Tomohiro Otani (KDDI) 77 otani@kddilabs.jp 78 Martin Vigoureux (Alcatel) 79 martin.vigoureux@alcatel.fr 81 2. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119. 87 3. Introduction 89 Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends 90 MPLS to support four new classes of interfaces Layer-2 Switch Capable 91 (L2SC), Time-Division Multiplex (TDM) capable, Lambda Switch Capable 92 (LSC) and Fiber-Switch Capable (FSC) in addition to Packet Switch 93 Capable (PSC) already supported by MPLS. However, most of the efforts 94 have been concentrated in facilitating the realization of seamless 95 control integration of IP/MPLS networks with SONET/SDH (see [T1.105]/ 96 [G.707]), OTH (see [G.709]) transport networks or Lambda. 98 However, while being introduced in [RFC3945], [GMPLS-RTG] and 99 [RFC3471], the GMPLS capability to control L2SC TE links and L2 LSPs 100 has received very little attention. [RFC3471] defines the Ethernet 101 encoding types (i.e. the encoding of the LSP being requested) and 102 Layer-2 as switching capability (i.e. the type of switching to be 103 performed on a particular link). In this document, a L2LSP is defined 105 D.Papadimitriou et al. - Expires November 2005 2 106 as a LSP being established between intermediate L2SC interfaces. 107 These interfaces are defined in [RFC3945] as being capable of 108 recognizing frame/cell boundaries and can switch data based on the 109 content of the frame/cell header (example: interfaces on Ethernet 110 switches that switch data based on the content of the MAC header). 112 Note that there is a difference between GMPLS control of Ethernet 113 switches (as described in this document) and MPLS transport over 114 Ethernet links as described in [RFC3032] or MPLS transport of 115 Ethernet [RFC3916]. In [RFC3032], packets are labeled using MPLS shim 116 headers and these are encapsulated in Ethernet frames targeted at the 117 next IP/MPLS LSR along the path. At the LSRs, the Ethernet header is 118 stripped and forwarding takes place based on the encapsulated MPLS 119 label. In [RFC3916], Ethernet frames are encapsulated and transported 120 over a packet-switched (e.g. MPLS) network. For both [RFC3032] and 121 [RFC3916], forwarding is based on packet headers, whereas GMPLS 122 control of L2LSPs is based on the Layer-2 frame header. 124 4. Objectives and Rationales 126 Service providers are extending the use of Ethernet beyond LAN 127 networks with the objective to provide more flexible capacity 128 management and simplified network management, as well as reduce 129 capital expenditure for network buildouts. However, Ethernet 802.1 130 bridges have limited scalability and network security support, and do 131 not provide the traffic engineering (TE) capabilities of (G)MPLS such 132 as DiffServ-TE (DS-TE). It also lacks scalable recovery mechanisms 133 for meshed networks e.g. re-routing. 135 This framework focuses on GMPLS usage with IEEE 802.3 Ethernet 136 networks. The scope of this document not only covers metro-core 137 network but also metro-access and aggregation networks. 139 Motivations for considering GMPLS control of L2 LSPs: 140 - automates the provisioning of Ethernet services such as 141 (virtual) private line and LAN services over GMPLS-capable networks 142 - facilitates the transport of client Ethernet flows without 143 requiring introducing additional intermediate packet layer LSPs, 144 that require themselves pre-provisioning actions as network trunks 145 - delivers a range of control plane driven recovery capabilities. 146 For instance, Ethernet Spanning Tree Protocol is less suitable in 147 meshed environments, whereas GMPLS control plane driven recovery 148 mechanisms are applicable 149 - simplifies the carrier network operations by avoiding dedicated 150 control protocols for managing Ethernet environments that are not 151 adapted for large scale environments and for which an IP-based 152 protocol counter-part exists (e.g. OSPF). 153 - uses IP based addressing that removes the scaling issues 154 generated by the non-hierarchical MAC addressing scheme. This GMPLS 155 capability allows constructing large scale, secure networks taking 156 advantage of IP addressing properties (at the control plane level). 157 - delivers a homogeneous set of signaling and TE mechanisms for 158 controlling L2 technologies to ease integration towards a common 160 D.Papadimitriou et al. - Expires November 2005 3 161 L1/L2/L3 control infrastructure capable of supporting various trust 162 models (e.g. overlay, unified) 164 5. Deployment Scenarios 166 5.1 Scenario 1: Access/Aggregation Networks 168 ISPs who deployed ATM based ADSL equipment are gradually replacing 169 them for reasons of capacity upgrade and CAPEX/OPEX reduction. While 170 Ethernet access technology facilitates simple installation as well as 171 easy configuration of Internet access with flexible usage demands, 172 some tradeoffs are the difficulties in providing QoS, user 173 authentication, and management. 175 |---RSVP--->| | 176 | |---- RSVP-TE Path ----> | 177 | | <--- RSVP-TE Resv ---| 178 | | |<-- RSVP --> 179 | |<====(L2 LSP Established)====>| 180 |<--RSVP----| | 181 +--------+ +-----------+ / 182 [H1]------| | =| | +-----------+ | Metro 183 [H2]-[L2]-|Ethernet|======|Aggregation|===|Edge Router|---| or Core 184 [H3]------| DSLAM | =| Switch | +-----------+ | Network 185 [H4]-[L2]-| | =| | GMPLS \ 186 +--------+ +-----------+ 187 GMPLS (GMPLS) ==== L2SC Link 189 Figure 1. GMPLS enabled L2SC switches in Aggregation Networks 191 For this scenario, an access aggregation network is a collection of 192 ISP devices that provides connectivity between a user terminal and 193 core network. Fig. 1 shows such a network where the access switch 194 (e.g. DSLAM) and edge router implement GMPLS L2SC capability. The 195 Aggregation switches may be Ethernet 802.1 or GMPLS L2SC capable 196 switches. Note, there can be a number of Ethernet 802.1 switches 197 between the end-hosts (H1 ~ H4) and the Access (e.g. DSLAM) switch, 198 between the access and the aggregation switch, and between the 199 aggregation switch and the edge router. The devices and aggregation 200 network elements may/may not be physically co-located, and different 201 ownership models may be applicable e.g. the access switch and edge 202 router may be owned by the service provider, whereas the aggregation 203 switch is owned by an independent access provider. 205 In Fig 1., a possible signaling scenario would entail an RSVP Path 206 message (RFC2205) initiated from customer premise via an access line 207 to the access switch. Policy can be imposed at the access switch to 208 examine the user's request. This triggers GMPLS RSVP-TE (RFC3473) for 209 L2LSP setup from the access switch towards the edge router. The GMPLS 210 RSVP-TE Path message is processed and forwarded until reaching the 211 edge router that is GMPLS L2SC capable. The GMPLS RSVP-TE message may 212 be forwarded without the aid of link-state routing protocols in the 213 access network (e.g. proxy). The edge router replies with a GMPLS 215 D.Papadimitriou et al. - Expires November 2005 4 216 RSVP-TE Resv message back to the access switch to complete 217 establishment of the L2LSP. As a result, an L2 LSP is established 218 between the access switch and the edge router. The initial RSVP Path 219 message may be tunneled and further processed beyond the edge router. 220 Otherwise, upon L2LSP completion, the access switch replies with a 221 RSVP Resv message to the initial RSVP request. 223 When the customer initiates data transmission, the access switch maps 224 the user flow into the L2 LSP. Mapping procedure is subject to 225 implementation choices, and is out of the scope of this document. 227 5.2 Scenario 2: Metro/Metro-core Networks 229 A metro-core network is a backbone that provides for Layer 2 and/or 230 Layer 3 connectivity across access and core networks. Currently, in 231 such environments, when an end-to-end "Ethernet connection" is 232 created based on a VLAN tag, their setting on each user port as well 233 as trunk port must be manually configured on each switch as shown in 234 Fig. 2. 236 +------+ +------+ +------+ 237 VLAN 1-+ L2SW | | L2SW | | L2SW +---VLAN1 238 | +---(VLAN1,2)---+ +---(VLAN1)---+ | 239 VLAN 2-+ #1 | | #2 | | #3 | 240 +---+--+ +---+--+ +---+--+ 241 | | | 242 | (VLAN2) | 243 | | | 244 +---+--+ +---+--+ +---+--+ 245 | L2SW | | L2SW | | L2SW +---VLAN2 246 | +---------------+ +---(VLAN2)---+ | 247 | #4 | | #5 | | #6 | 248 +------+ +------+ +------+ 250 Fig. 2: End-to-end connection based on VLAN in Ethernet network 252 In addition, the path may be manually selected and may be neither 253 shortest, nor optimal. To solve these issues, GMPLS label control 254 would be used for assigning VLAN tags to Ethernet ports and trunks, 255 so that the "connection" can be established as a VLAN-based label 256 switched path (LSP). The latter may be mapped on a lower layer LSP. 258 GMPLS RSVP-TE is used to support the Ethernet "connection" i.e. L2LSP 259 setup. OSPF-TE/IS-IS TE is used to disseminate TE routing information 260 about ports. Bandwidth of each VLAN "connection" or the bandwidth of 261 each port can be treated as a constraint of CSPF for path 262 computation. GMPLS traffic engineering can be applied, and multiple 263 ownership/trust models (e.g. overlay, peer) may be applied. 265 5.3 Scenario 3: Unified Network 267 This scenario depicts the integration of packet, Ethernet and circuit 268 switching under a unified GMPLS control plane. In Fig 3, a "PSC LSR" 270 D.Papadimitriou et al. - Expires November 2005 5 271 is a packet based MPLS LSR, "L2SC LSR Ethernet" a GMPLS controlled 272 Ethernet switch, "LSC LSR Lambda" a GMPLS controlled optical switch. 273 In Fig 3, L2/L1 LSP refer to a Layer 2 LSP (L2LSP) over L1 LSP. 275 A L2 LSP B L2/L1 LSP C 276 +-------+ +---------+ +---------+ 277 | PSC | | L2SC | | LSC | 278 | LSR |--------| LSR |---------| LSR |------+ 279 | | |Ethernet | | lambda | | 280 +-------+ +---------+ +---------+ | 281 | L2/L1 LSP 282 +-------+ +---------+ +---------+ | 283 | PSC | | L2SC | | LSC | | 284 | LSR |--------| LSR |---------| LSR |------+ 285 | | |Ethernet | | lambda | 286 +-------+ +---------+ +---------+ 287 F L2 LSP E L2/L1 LSP D 289 Figure 3: Data plane 291 Fig.4 shows the relationships between the control and data plane 292 entities in a GMPLS enabled network where the three data planes are 293 controlled by the same GMPLS control plane instance. 295 +-----------+ +-------------+ +-------------+ 296 | A | | B | | C | 297 | +-------+ | | +---------+ | | +---------+ | 298 | | PSC | |OSPF-TE| | L2SC | |OSPF-TE| | LSC | | 299 | | LSR |<--------->| LSR |<--------->| LSR | | control 300 | | | |RSVP-TE| |Ethernet | |RSVP-TE| | CP | | plane 301 | +-------+ | | +---------+ | | +---------+ | 302 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 303 | +-------+ | | | | | 304 | | PSC | | | | | | 305 | | LSR |----+ | | | | IP/MPLS 306 | | | | | | | | | 307 | +-------+ | | | | | | 308 +-----------+ | | | | | 309 .................................................................... 310 | | +---------+ | | | 311 | | | L2SC | | | | 312 +------| LSR |----+ | |Ethernet 313 | |Ethernet | | | | | 314 | +---------+ | | | | 315 +-------------+ | | | 316 .................................................................... 317 | | +---------+ | 318 | | | LSC | | 319 +------| LSR | |lambda 320 | | lambda | | 321 | +---------+ | 322 +-------------+ 324 D.Papadimitriou et al. - Expires November 2005 6 325 Figure 4. Data plane and control plane 327 In this multi-region scheme, aggregation of traffic onto the same LSP 328 is possible. In analogy with having packet coming in to an LER 329 (ingress LSR) with the same Forwarding Equivalence Class (FEC) mapped 330 on to the same MPLS LSP, it possible to select one or several of 331 these LSPs onto the same L2LSP if the are to be forwarded to the same 332 egress point in the Ethernet network. 334 In a further step, nesting of LSP e.g. Packet LSPs into an Ethernet 335 L2LSP can be considered. Ethernet L2LSPs can also be nested into 336 lambda LSPs. In Figure 5 a through j are different types of LSPs. a, 337 b and c are packet switched LSPs entering the packet switch capable 338 LSR (A), those LSPs are carried on the L2LSP e from node A to B. d, e 339 and f are Ethernet LSPs entering the L2 switch capable LSR (B), those 340 LSPs are carried over a lambda LSP h from node B to C. g, h and i are 341 lambda LSPs entering the lambda switch capable LSR (C), those LSPs 342 are carried over a lambda LSP j from node C. 344 a A d B g C 345 | +-------+ | +---------+ | +---------+ 346 +--| | +-->| | +-->| | 347 | PSC | | L2SC | | LSC | 348 b----| LSR |e------>| LSR |h------->| LSR |j-----> 349 | | |Ethernet | | lambda | 350 +--| | +-->| | +-->| | 351 | +-------+ | +---------+ | +---------+ 352 c f i 354 Figure 5: LSPs in LSPs 356 The routing protocol envisaged for this type of network is OSPF-TE, 357 some extension to OSPF-TE MAY be required (the same applies when 358 considering ISIS-TE). The signaling protocol is RSVP-TE that needs to 359 be extended by a definition of an Ethernet label space (see Section 360 6.2). 362 5.4 Scenario 4: Transport Networks 364 In this scenario, the network is constituted by a core network 365 including core-nodes (CN) surrounded by edge nodes (EN) that form the 366 overlay (control plane) networks. This scenario supports various 367 trust models and signaling models. An overlay trusted model may be 368 supported, allowing the core to hide its topology from the edge-nodes 369 and permitting the core restrictive actions towards the edge nodes 370 (e.g. filtering out specific RSVP objects). In addition, this 371 scenario supports networks where the core uses a non-GMPLS based 372 control plane (or no control plane e.g. management plane). 374 EN-CN (and CN-EN) TE links are of type [X,L2SC], ([L2SC,X] resp.), 375 where X is any ISC whose switched payload can be carried over L2SC TE 376 links. Within the network, TE links interconnecting CNs can be either 377 [L2SC,L2SC] or any other technology that can carry Layer-2 payload. 379 D.Papadimitriou et al. - Expires November 2005 7 380 B---C F---G 381 UNI / \ E-NNI / \ UNI 382 EN1-----A 1 CN1-------CN2 2 H-----EN2 383 \ / \ / 384 E---D J---I 386 Figure 6: GMPLS Ethernet in Overlay Transport Networks 388 The core networks 1 and 2 are interconnected by two CNs (CN1 and 389 CN2), that define an external network-network interface (E-NNI). 390 Within core network 1, [A,B] and [A,E] are [L2SC,Y] TE links. Within 391 core network 2, [G,H] and [I,H] are [Y,L2SC] TE links. 392 - When [C,CN1] and [D,CN1] are [Y,L2SC] TE Links, [CN2,F] and 393 [CN2,J] are [L2SC,Y] TE Links, and [CN1,CN2] is a [L2SC,L2SC] TE 394 link, the L2 LSP that can be setup between node EN1 (ingress) and 395 node EN2 (egress) is constituted by two LSP segments of type Y. 396 The first LSP segment between A and CN1 and the second between CN2 397 and H. These segments are inter-connected by the [L2SC,L2SC] TE 398 link defined at the E-NNI. The intermediate GMPLS L2SC hops for 399 this L2 LSP are thus A, CN1, CN2 and H. 400 - When these conditions are not met, in particular, when the 401 [CN1,CN2] link is of type e.g. [Y,Y], the L2 LSP that can be setup 402 between node EN1 (ingress) and node EN2 (egress) is constituted by 403 one LSP segment of type Y defined between A and H. The 404 intermediate GMPLS L2SC hops for this L2 LSP are thus A and H. 406 6. Requirements 408 6.1 Control plane scope 410 Nodes playing an active role in signaling and routing MUST support 411 the GMPLS capabilities required by the present section. Their 412 implementation SHOULD minimize overhead and manual configuration. 414 The IP control channel between GMPLS L2SC nodes can be out-of-band 415 or in-band. Signaling and routing information exchange between 416 adjacent GMPLS nodes and processing MUST be strictly independent of 417 the control channel implementation. 419 6.2 Labeling and Label scope requirements 421 A GMPLS labeled frame is an Ethernet frame whose header encodes the 422 label value. GMPLS Ethernet switches SHOULD be able to correctly 423 handle all types of Ethernet MAC frames, including the GMPLS labeled 424 frames, to ensure inter-working with 802.1 bridges. 426 The label's interpretation depends on the type of the link over which 427 the label is used. Labels are locally assigned, interpreted and have 428 local significance. This does not preclude that the same label value 429 can be assigned by consecutive hops (e.g. as it is the case in 430 Scenario 2). 432 D.Papadimitriou et al. - Expires November 2005 8 433 Label value space is assumed to be independent of the implementation 434 of the Ethernet frame forwarding/switching. 436 6.4 Link Discovery 438 Nodes are inter-connected by point-to-point L2SC links. GMPLS L2SC 439 nodes MUST support discovery of per TE link capabilities. 441 In addition, GMPLS link discovery SHOULD provide 442 - data link property correlation to support aggregating multiple data 443 links into a single TE Link and to synchronize their properties 444 - data link verification to verify the data links physical 445 connectivity and verify the mapping of the Interface ID to Link ID 446 and their local-remote associations 448 Optionally, fault management MAY be provided to suppress alarms and 449 localize failures. 451 Extensions to LMP MAY be required to deliver this functionality. 453 6.5 Routing Advertisement and Traffic Engineering 455 To facilitate IGP operations such as forming neighbor adjacencies, 456 flooding link state database packets, and representing topology, 457 routing SHOULD treat the broadcast point-to-point control channel 458 between adjacent LSRs as a point-to-point circuit [IGP-LAN]. 460 The solution MUST support the exchange of TE (intra-domain) and 461 reachability (intra and inter-domain) information across the GMPLS 462 Ethernet network(s). 464 Scenario 3 that relies on a unified TE control plane SHALL be able to 465 take TE decisions such as congestion avoidance and recovery actions 466 at the optimal layer. 468 6.6 Implication(s) on Signaling 470 Signaling mechanisms MUST apply to bi-directional L2LSP setup and 471 where appropriate unidirectional L2LSP setup. Interface 472 identification MUST follow the rules defined in [RFC3473], Section 473 8.1 and [RFC3477]. 475 6.6.1 RSVP Signaling 477 GMPLS RSVP-TE signaling for setup/teardown of L2LSP (across GMPLS 478 Ethernet switches) MUST keep RSVP sessions end-to-end significant. 480 L2LSP notification and graceful deletion procedures [RFC3473] SHOULD 481 be supported. Graceful Restart upon control channel and node failure 482 SHOULD also be supported. 484 D.Papadimitriou et al. - Expires November 2005 9 485 Scenarios providing aggregation capability SHOULD support nesting of 486 L2LSPs or PSC LSPs into a FA (L2) LSP when the head/tail end-nodes 487 provide de/multiplexing capabilities. 489 L2LSP splicing (see [RFC3471]) and L2LSP stitching [RSVP-ID] MUST be 490 envisioned in the context of multi-domain L2LSP environments. The 491 solution MUST support both overlay [GMPLS-UNI] and inter-domain 492 [framework] signaling models. 494 6.6.2 L2 Label Request 496 The Generalized Label Request is defined in [RFC3471], Section 3.1. 497 The LSP Encoding Type and Switching Type to be used for requesting 498 L2 LSP label are Ethernet and L2SC respectively. Generalized PID (G- 499 PID) that identifies the payload carried by Ethernet L2LSPs MUST use 500 standard Ethertype values. 502 6.6.3 L2 Traffic Parameters 504 Per [RFC3471], GMPLS allows the inclusion of technology specific 505 parameters in signaling. These parameters MUST include the L2 link 506 type that comprises the requested LSP e.g. Ethernet Port and the MTU 507 value. They MUST also be capable to describe traffic parameters for 508 this L2LSP such as the Peak Rate (PIR and PBS), the Committed Rate 509 (CIR and CBS), and the Excess Rate (EIR and EBS). 511 6.6.4 L2 Label 513 L2 Label follows the rules defined in [RFC3471]. The interpretation 514 of the received label depends on the type of the link over which the 515 label is used. The received label MUST be interpreted according the 516 requestor traffic parameters i.e. a label by itself does not allow 517 knowing the detailed properties of the L2 LSP being requested (i.e. 518 L2 labels are context sensitive). 520 Bi-directional L2 LSPs are indicated by the presence of an upstream 521 label in the Path message. 523 6.6.5 Explicit Routing support 525 Explicit and Record routing MUST be supported for scenarios making 526 use of source routing such as to provide constraint based routing 527 (for resource and/or data traffic oriented TE) and loop avoidance. 529 Explicit routing, when used, MUST follow the procedures defined in 530 [RFC3209], [RFC3473], and [RFC3477]. 532 Record routing, when used, MUST follow the procedures defined in 533 [RFC3209], [RFC3473], and [RFC3477]. 535 Explicit label control SHOULD be supported (see [RFC4003]) at least 536 in scenario 2 and 4. 538 D.Papadimitriou et al. - Expires November 2005 10 539 7. Reference other SDOs 541 7.1 IEEE 802.1 543 The IEEE specifies elements of switching in Ethernet networks. They 544 should be consulted on the scenarios and framework proposed in this 545 document and any solutions developed in the IETF context should be 546 reviewed by the appropriate IEEE working groups to ensure the 547 solution is not harmful to 802.1 networks. 549 There have been several approaches specified by IEEE to overcome the 550 Scaling limitations and to extend service of Ethernet LAN across MAN 551 and WAN, such as IEEE Provider Bridge [802.1ad] and Provider Backbone 552 Bridge [802.1ah]. 554 7.2 ITU-T SG15 556 SG15 is currently defining Ethernet Transport Network architecture 557 and services e.g. EPL, EVPL, EPLan and EVPLan. Specific work items 558 are also dedicated to the definition of Ethernet OAM, traffic 559 management and performance as well as the definition of Ethernet UNI 560 and NNI. 562 During revision of the Recommendation G.8010 on defining Ethernet 563 transport network, the IETF ASON/GMPLS control plane definition 564 (including Point-to-point and multi-point ETH VC set up, 565 modification, teardown, etc.) should be positioned as another 566 operation mode analogous to IEEE 802.1 PB and PBB. 568 8. Security considerations 570 The introduction of L2 LSP, particularly in Ethernet networks, 571 raises similar security issues such as with L1 LSPs and additional 572 L2-specific security issues that need to be solved. The solution 573 MUST protect against the following security threats: 574 - Possibility for the network to control the traffic injected by the 575 client in the data plane (BPDU, Multicast, Broadcasts, etc.) or in 576 the control plane (RSVP-TE signaling messages) 577 - All usual threats brought by IP functionalities (control and data 578 plane) 579 - Entry points induced by the possible coexistence of the two 580 technologies (L2LSPs and usual Broadcast Ethernet mode) 582 Current RSVP security mechanisms [RFC2207], [RFC3097] should also be 583 analyzed/evaluated in the context of L2 LSPs. 585 8.1 Attacks on the Data Plane 587 This category encompasses attacks on the data plane. Attacks on the 588 data plane can be of the following form: 589 - modification of data traffic 590 - insertion of non-authentic data traffic 591 - Denial of Service (DoS) attacks 593 D.Papadimitriou et al. - Expires November 2005 11 594 - traffic snooping 596 Introduction of L2 LSP signaling MUST prevent these attacks by 597 offering adequate filters (like ACLs or some new means). 599 L2 LSP SHOULD reduce data plane threats, as the number of network 600 entry points to control is reduced. A L2 LSP is by nature a hermetic 601 tunnel, with a single entry point (head-end LSR). Policing and 602 filtering is required only on the head-end LSR. 604 Moreover, some mechanisms MUST be provided at the network edges (on 605 the head-end LSRs) to rate limit the amount of traffic that can 606 transit into a given L2 LSP. 608 8.2 Attacks on the Control Plane 610 There are two threats concerning the control plane. The first one 611 corresponds to the support of signaling by the client side. As LSP 612 tunnels MAY be signaled from the client site using RSVP-TE, control 613 of such activity MUST be provided so that it cannot be used to fail 614 the entire network. Different trust models MUST be supported. 616 There MUST be a way to limit, by configuration, the number of L2LSPs 617 that can be signaled by a particular client, also there must be a 618 way to rate limit RSVP-TE client control plane traffic (mainly 619 refresh interval). Also the operator MUST be able to rate limit, by 620 configuration, the total amount of memory and/or CPU allocated to 621 the RSVP engine, and react appropriately when such bound is reached. 623 Another threat comes from the introduction of IP control functions 624 in L2 equipments (such as the handling of multicast). GMPLS Ethernet 625 networks will inherit the security issues of IP networks similar to 626 other GMPLS client networks, and the appropriate trust models MUST 627 be supported. 629 8.3 Security problems induced by the migration 631 If both L2 LSPs and classical Ethernet are used on the same network, 632 then different ranges of VLANs must be considered so that the 633 different traffics, with different VLAN semantics, do not get mixed 634 for example. 636 9. Acknowledgments 638 The authors would like to thank X, Y and Z. 640 10. References 642 10.1 Normative References 644 [RFC2205] R.Braden (Editor) et al., "Resource ReserVation 645 Protocol -- Version 1 Functional Specification", RFC 646 2205, September 1997. 648 D.Papadimitriou et al. - Expires November 2005 12 650 [RFC2210] J.Wroclawski, "The Use of RSVP with IETF Integrated 651 Services", RFC 2210, September 1997. 653 [RFC2961] L.Berger et al., "RSVP Refresh Overhead Reduction 654 Extensions", RFC 2961, April 2001. 656 [RFC3034] A.Conta et al., "Use of Label Switching on Frame Relay 657 Networks Specification", RFC 3034, January 2001. 659 [RFC3035] B.Davie et al., "MPLS using LDP and ATM VC Switching", 660 RFC 3035, January 2001. 662 [RFC3036] L.Andersson et al., "LDP Specification", RFC 3036, 663 January 2001. 665 [RFC3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 666 LSP Tunnels", RFC 3209, December 2001. 668 [RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol 669 Label Switching (GMPLS) - Signaling Functional 670 Description", RFC 3471, January 2003. 672 [RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol 673 Label Switching (GMPLS) Signaling Resource ReserVation 674 Protocol-Traffic Engineering (RSVP-TE) Extensions", 675 RFC 3473, January 2003. 677 [RFC3477] K.Kompella and Y.Rekhter, "Signalling Unnumbered 678 Links in Resource ReserVation Protocol-Traffic 679 Engineering (RSVP-TE)", RFC 3477, January 2003. 681 [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, 682 RFC 3667, February 2004. 684 [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF 685 Technology", BCP 79, RFC 3668, February 2004. 687 [RFC3945] E.Mannie (Editor) et al., "Generalized Multi-Protocol 688 Label Switching (GMPLS) Architecture", RFC 3945, 689 October 2004. 691 10.2 Informative References 693 [BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic 694 Engineering", Internet Draft, Work in Progress, draft- 695 ietf-mpls-bundle-06.txt, July 2005. 697 [GMPLS-UNI] G.Swallow et al., "GMPLS UNI: RSVP Support for the 698 Overlay Model", Internet Draft, Work in Progress, draft- 699 ietf-ccamp-gmpls-overlay-06.txt, October 2004. 701 D.Papadimitriou et al. - Expires November 2005 13 703 [GMPLS-RTG] K.Kompella and Y.Rekhter (Editors) et al., "Routing 704 Extensions in Support of Generalized MPLS", Internet 705 Draft, Work in Progress, draft-ietf-ccamp-gmpls-routing- 706 09.txt, October 2003. 708 [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with 709 Generalized MPLS TE", Internet Draft, Work in Progress, 710 draft-ietf-mpls-lsp-hierarchy-08.txt, September 2002. 712 [IGP-LAN] N.Shen and A.Zinin, "Point-to-point operation over LAN 713 in link-state routing protocols", Internet draft, 714 Work in progress, draft-ietf-isis-igp-p2p-over-lan- 715 05.txt, July 2004. 717 11. Author's addresses 719 Dimitri Papadimitriou (Alcatel) 720 Francis Wellensplein 1, 721 B-2018 Antwerpen, Belgium 722 Phone: +32 3 240 8491 723 EMail: dimitri.papadimitriou@alcatel.be 725 Jaihyung Choi (ETRI) 726 Email: jaihyung@etri.re.kr 728 D.Papadimitriou et al. - Expires November 2005 14 729 Intellectual Property Statement 731 The IETF takes no position regarding the validity or scope of any 732 Intellectual Property Rights or other rights that might be claimed 733 to pertain to the implementation or use of the technology described 734 in this document or the extent to which any license under such 735 rights might or might not be available; nor does it represent that 736 it has made any independent effort to identify any such rights. 737 Information on the procedures with respect to rights in RFC 738 documents can be found in BCP 78 and BCP 79. 740 Copies of IPR disclosures made to the IETF Secretariat and any 741 assurances of licenses to be made available, or the result of an 742 attempt made to obtain a general license or permission for the use 743 of such proprietary rights by implementers or users of this 744 specification can be obtained from the IETF on-line IPR repository 745 at http://www.ietf.org/ipr. 747 The IETF invites any interested party to bring to its attention any 748 copyrights, patents or patent applications, or other proprietary 749 rights that may cover technology that may be required to implement 750 this standard. Please address the information to the IETF at 751 ietf-ipr@ietf.org. 753 Disclaimer of Validity 755 This document and the information contained herein are provided on 756 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 757 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 758 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 759 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 760 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 761 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 Copyright Statement 765 Copyright (C) The Internet Society (2005). This document is subject 766 to the rights, licenses and restrictions contained in BCP 78, and 767 except as set forth therein, the authors retain all their rights. 769 Acknowledgment 771 Funding for the RFC Editor function is currently provided by the 772 Internet Society. 774 D.Papadimitriou et al. - Expires November 2005 15 775 12. Full Copyright Statement 777 Copyright (C) The Internet Society (2004). This document is 778 subject to the rights, licenses and restrictions contained in BCP 779 78, and except as set forth therein, the authors retain all their 780 rights. 782 This document and the information contained herein are provided 783 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 784 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 786 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 787 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 788 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 789 PARTICULAR PURPOSE. 791 D.Papadimitriou et al. - Expires November 2005 16