idnits 2.17.1 draft-dimitri-gels-solution-eval-00.txt: -(7): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. ** 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 6 instances of lines with non-ascii characters in the document. == 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 Introduction section. ** 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 == Line 655 has weird spacing: '...d. This subse...' -- 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 2006) is 6645 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: 'GELS-FRM' is mentioned on line 358, but not defined == Missing Reference: 'GELS-REQ' is mentioned on line 299, but not defined == Missing Reference: 'STITCHING' is mentioned on line 270, but not defined == Missing Reference: 'RFC 4206' is mentioned on line 313, but not defined == Missing Reference: 'CCAMP-ID-FRM' is mentioned on line 908, but not defined == Unused Reference: 'RFC2119' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC3784' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 1120, but no explicit reference was found in the text == Unused Reference: 'MRN-REQ' is defined on line 1126, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- No information found for draft-ietf-ccamp-gmpls-mrn-reqs - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Papadimitriou (Alcatel) 3 Internet Draft N. Sprecher (Siemens) 4 J. Cho (ETRI) 5 Expires: July 2006 L. Andersson (Acreo AB) 6 D. Fedyk, D.Allan (Nortel) 7 A. Tak�cs (Ericsson) 8 D. Caviglia (Ericsson) 10 February 2006 12 Label Encoding Solution Decoder and Analysis 13 for GMPLS-controlled Ethernet Label Switching (GELS) 15 draft-dimitri-gels-solution-eval-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 For potential updates to the above required-text see: 40 http://www.ietf.org/ietf/1id-guidelines.txt 42 Abstract 44 This document introduces the functional criteria as a decoder ring 45 for the selection of GELS label encoding. After detailing each 46 proposed label encoding, each solution is analyzed against these 47 criteria. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119 [i]. 55 Reader is also assumed to be familiar with the GELS framework [GELS- 56 FRM]. 58 1. Terminology 60 L2SC Label Switch Router (LSR): LSR whose interfaces are capable to 61 recognize Layer 2 frame boundaries and can switch data based on the 62 content of the Layer 2 frame header. In the context of this document, 63 L2SC interfaces are limited to Ethernet interfaces. 65 Ethernet Label Edge Router (E-LER): LER that resides either at the 66 edge of the provider's GMPLS network (a.k.a. Provider Edge or PE) or 67 at the edge to customer's network (a.k.a. Customer Edge or CE). In 68 the former case, the Ethernet LER interfaces the customer�s network 69 equipment. The E-LER has the functionality required for initiating 70 and terminating point-to-point and point-to-multipoint Ethernet 71 connectivity across the GMPLS network. 73 Ethernet Label Switching Router (E-LSR): LSR that either resides at 74 the core of the provider's GMPLS network (a.k.a. Provider node or P) 75 or at the edge to provider's GMPLS network (a.k.a. Provider Edge or 76 PE). In the former case, the Ethernet LSRs have no direct interfaces 77 towards the customers' networks. The Ethernet LSR performs Ethernet 78 label switching operation by means of a LIB configured by GMPLS. 80 Ethernet Label Switched Path (LSP): Label Switched Path established 81 between two Ethernet LERs (ingress and egress) using GMPLS signaling 82 or between one ingress Ethernet LER and multiple egress LERs. In the 83 former case, one refers to a point-to-point Ethernet LSP and in the 84 latter to a point-to-multipoint Ethernet LSP. 86 Label Information Base (LIB): table that specifies associations 87 between incoming and outgoing Ethernet Labels included in Layer 2 88 frame headers and outgoing ports. If different to the incoming label 89 it also specifies the outgoing label. 91 Connection Oriented Ethernet: defined by LSPs having a single source 92 (ingress Ethernet LERs) and one or multiple destinations (egress 93 Ethernet LERs). LSPs must be created before any Ethernet PDUs can be 94 sent, but exist independently of whether any PDUs are being sent. 95 There is no further routing choice within the LSP. These LSPs 96 maintain ordering of Ethernet PDUs sent from source. 98 2. Functional Criteria 100 This section attempts to set functional criteria for examining, 101 analyzing and comparing the optional solutions listed in Section 3. 102 Naturally, the first and the most important criterion should be 103 compliance with the GELS requirements [GELS-REQ]. 105 At time of writing, this document was not finalized; hence, it may be 106 thus necessary to tune and adjust this section on completion of the 107 requirement draft. 109 A description of the criteria follows. These functional criteria are 110 solution independent and intended to simplify the GELS solution (in 111 terms of label encoding) selection process for implementing 112 connection-oriented Ethernet. Note that the order in which the 113 criteria are specified does not imply the order of importance. 115 2.1 Ethernet P2P and P2MP TE LSPs 117 Point-to-point (uni and bi-directional) and point-to-multipoint 118 (unidirectional) connections are defined by trails, which have the 119 property of being directed with a single source and one or multiple 120 destinations. Traffic flows should be identified by some connection 121 identifiers rather than by explicitly listing source and destination 122 addresses. This makes Ethernet frame switching substantially faster 123 (as FIDs are just simple look-up tables and are easy to implement in 124 the hardware). 126 In a connection-oriented Ethernet environment, p2p and p2mp 127 connections must be used to construct all other networking services 128 like mp2p and mp2mp services (see Section 2.3). That is, in 129 connection-oriented Ethernet, p2p and p2mp connections are the 130 primary focus that determines the underlying Ethernet label encoding 131 scheme. 133 Connection-oriented Ethernet enables the setting up of p2p and p2mp 134 LSPs based on the service definition and the enforcement of the SLA. 135 Connection oriented Ethernet also requires pre-provisioning of the 136 network connections and that the required resources are pre-allocated 137 and reserved. The solutions should enable realization of the Traffic 138 Engineering resource-oriented (to optimize the network resource 139 usage) and traffic-oriented (delay, jitter, loss, etc.) performance 140 objectives based on the service definition to enforce the SLA. 142 2.2 Ethernet LSP Merging and LSP Multiplexing 144 LSP merging is referred when at a network element multiple point-to- 145 point LSP segments are joined into a single point-to-point LSP 146 segment in a way that no further differentiation between the original 147 LSP segments is possible. 149 LSP multiplexing is the case when the joined point-to-point LSP 150 segments can be differentiated later on in particular at the common 151 receiver. There are two cases of multiplexing: 152 - a separate label is assigned on a per sender basis 153 - a common label is assigned independently of the sender 155 The GELS framework discusses local vs. domain-wide labels 156 (identifiers). While local labels provide simple method for LSP 157 merging and multiplexing, usage of domain-wide labels results in 158 dependence to the structure and the nature of the label. 160 It must be noted that merging in contrast to multiplexing does not 161 preserve the possibility to identify the source of the corresponding 162 LSP(s). 164 LSP merging and multiplexing deliver a way to provide mp2p services 165 but impact network operation and maintenance requirements: 166 (1) ability to identify specific faulty connections (using OAM 167 mechanisms) 168 (2) ability to police individual senders and connections. 170 Therefore, LSP merging and multiplexing are optional capabilities to 171 be supported by the solution. 173 2.3 Services 175 The solution should be capable of providing any connectivity service 176 that is supported by standard Ethernet encapsulation (such as 177 IP/MPLS, TDM, etc.). 179 The solution should not constraint the connectivity services delivery 180 by the network. 182 The solution should provide efficient means to simplify the 183 provisioning task in the following aspects: 185 1. The label distribution and allocation process should have a 186 minimum effect on the network so as to reduce provisioning overhead, 187 as well as to relieve the network synchronization process. 189 2. Network configuration, provisioning and adjustment should have a 190 minimum effect on the network and services it delivers. 192 3. The solution should support network trunks in order to simplify 193 the delivery of services. 195 2.4 OAM 197 The solutions should provide means to simplify the network operations 198 maintenance task. 200 The use Ethernet OAM is required to monitor the proper operation of 201 the network. 203 The solutions should provide a means to minimize the number of LSPs 204 that should be monitored. Only network trunks (nesting LSPs) should 205 be monitored and there is no specific requirement to monitor the 206 services within the tunnels. Services may be monitored according to 207 specific service requirements. 209 The solutions should enable the support for OAM (IEEE 802.1ag) 210 messages. The following mechanisms should be supported to detect 211 failures or problems in the network and to ensure the correct 212 operation of the network: 213 1) Connectivity verification 214 2) Alarm communication and handling 215 3) Loopback tests 216 4) Fault diagnosis (e.g. traceroute) 218 2.5 Resiliency 220 Network resiliency is the network's ability to restore traffic 221 following failure or attack, and is a critical factor in delivering 222 reliable services. 224 Guaranteed service in the form of SLAs requires a resilient network 225 that instantaneously detects facility or node failures and 226 immediately restores network operation to meet the terms of the SLA. 228 The solution should provide mechanisms 229 o) to match the sub 50 ms failover times required to maintain time- 230 bounded services. The solutions should also support recovery 231 mechanisms that save network resources, that is, without pre- 232 provisioning of bandwidth. For this kind of recovery mechanisms the 233 failover time can be higher that 50 ms. 235 o) to protect against any failure in the network (including failure 236 of boundary nodes in case of inter-domain operation). 238 The recovery mechanisms are categorized as end-to-end LSP recovery 239 (global protection), LSP segment recovery, and local LSP recovery. 241 The solutions should assure the correct inter-working between control 242 plane and data plane (e.g. port protection) recovery mechanism. 244 2.6 Inter-domain 246 The solutions should enable the provisioning of Ethernet LSPs over 247 inter-domains. The peering and the client/server interconnection 248 modes are considered, as follows: 250 (i) Peering mode: Peering is a way of interconnection, where the 251 interfacing between the domains/operators is defined by UNI/E-NNIs. 252 Moreover, peering networks exchange traffic at the same networking 253 layer, that is layer N traffic arriving for domain A will be 254 forwarded in domain B as layer �N� traffic as well. It is possible to 255 further subdivide this mode depending on which topology (addresses, 256 resources, etc.) information are exchanged across the UNI/E-NNI 257 interface. 259 (ii) Client-server mode: The client/server mode of interconnection, 260 the server operator provides a networking service that delivers the 261 client�s traffic. Essentially, the client�s traffic resides on layer 262 N and it transported transparently across the server layer N-1. The 263 identifiers from the client layer and the server are independent. A 264 natural example of this mode of operation is an Ethernet flow (layer 265 N) transported via an SDH/SONET circuit (layer N-1). 267 In certain scenarios, there may be a need to combine together 268 different LSPs such that in the data plane, a single end-to-end LSP 269 is realized and all traffic from one LSP is switched onto the other 270 LSP. This operation is called LSP stitching [STITCHING]. 272 The solutions should support LSP stitching. 274 2.7 Scalability 276 2.7.1 MAC Address 278 By nature, a solution for connection-oriented Ethernet should be 279 agnostic with regard to MAC address learning such as to eliminate the 280 FIB flush associated with topology change and flooding operations, 281 which lead to slow recovery and convergence. 283 2.7.2 VLAN ID (VID) 285 The scalability of the solution should not be impacted by the limited 286 space of VLAN identifier (VID). 288 2.7.3 Ethernet Frame Switching 290 Ethernet frame switching should be independent of the destination MAC 291 address and SHOULD NOT rely on the customers' destination MAC 292 addresses. 294 2.7.4 Label 296 The scalability of the label value space (and hence its encoding) 297 constraints the number of LSPs that can be concurrently provisioned. 298 The solutions should therefore provide label value and encoding that 299 allow a satisfactory number of LSPs to be provisioned [GELS-REQ]. 301 In addition, the Ethernet label is encoded in the Ethernet MAC frame 302 header. Therefore, the size of the label affects the frame and the 303 length of the payload. 305 Scalability also depends on the size of the label and its implication 306 on the Ethernet frame header size, e.g. MAC encapsulation (DA_B-MAC) 307 in combination with B-TAG etc. or S-TAG (S-VID). 309 2.7.5 LSP Hierarchy 311 LSP hierarchy can be used to improve the network scalability, the 312 solutions should assure that label encoding is not constraining 313 Forwarding adjacency LSP establishment [RFC 4206]. 315 2.8 Backward compatibility with IEEE 802.1 317 The label encoding techniques MUST make use of the structure of the 318 standard IEEE 802.1 Ethernet frame and frame header. 320 The encoding solution should not modify the format of the standard 321 Ethernet frame or the standard Ethernet frame header but may add new 322 semantics to one or more fields. 324 Where the solution should co-exist with IEEE 802.1 bridge control and 325 management functionalities on the same network element it should be 326 backward compatible with legacy Ethernet bridges. In this case, GMPLS 327 Ethernet switches need to be capable of handling all types of 328 Ethernet MAC frames, including GMPLS-labeled frames, to ensure their 329 co-existence with legacy Ethernet switches. 331 2.9 Applicability 333 The solutions should be examined for each network scenario. It may be 334 that a specific solution is found to be more appropriate for a 335 certain network scenario while a different solution is more suitable 336 for another type of scenario. 338 The solutions should be examined with respect to their deployment in 339 the following types of networks: 340 1) Metro access and Metro aggregation networks 341 2) Metro core 342 3) Core and transport networks 344 These scenarios should enable services to scale effectively as the 345 customer base grows, in order to minimize capital expenditures and 346 drive down operational costs. 348 2.10 Security 350 The solution should provide a means to protect the network from the 351 following threats: 352 1) Vulnerability to unwanted connectivity (through malicious 353 attacks). 354 2) MAC spoofing and MAC attacks. 355 3) VLAN ID attacks. 357 The threats that concern the control plane are described in section 358 5.4.1 of [GELS-FRM] and are not relevant in the present context. 360 3. Solution Description 362 GMPLS makes use of the structure of the standard IEEE 802.1 Ethernet 363 frame. The Ethernet label is inserted in the Ethernet encapsulation 364 and is part of the Ethernet MAC frame header. A GMPLS Ethernet- 365 labeled frame is defined as an Ethernet MAC frame whose header 366 encodes the label value. The coding of the Ethernet label does not 367 modify the format of the standard Ethernet frame, although it may add 368 new semantics to one or more fields. The switching decision is based 369 on the label part of the Ethernet frame header. Figure 4 depicts a 370 logical view of the protocol layers. 372 +---------------------------+ 373 | Payload | 374 +---------------------------+ 375 | Ethernet | 376 +---------------------------+ 377 | Physical | 378 +---------------------------+ 380 Figure 4: Logical Protocol Layering Model 382 The Ethernet MAC frame header includes the EtherType, different VLAN 383 TAGs, as well as the destination and source MAC addresses. 385 GMPLS functionality can co-exist with IEEE 802.1 bridge control and 386 management functionalities on the same network element. The common 387 network resources should be either pre-partitioning or dynamically 388 selected. 390 The architecture allows different label encoding techniques. A 391 specific encoding technique may be selected according to the 392 capability of the GMPLS-enabled Ethernet network element and/or to 393 the capability of the label-controlled Ethernet interface, etc. 395 Ethernet label and label switching technique must be extensible for 396 the establishment and support of multiple-domain Ethernet LSP, point- 397 to-multipoint LSPs (carrying Ethernet multicast traffic) and easily 398 support exchange of Ethernet broadcast traffic. 400 The following techniques are considered as candidate for the encoding 401 of the Ethernet label. 403 3.1 S-VID Translation 405 3.1.1 Label Encoding 407 This link-local label technique makes us of the IEEE 802.1ad S-VID 408 (amendment to IEEE Std 802.1Q-1998) S-VID translation mechanism. 410 The idea behind this solution is to prevent the control plane from 411 dealing with any MAC address space specifics such as to ensure 412 independence and transparency to the data plane addressing specifics. 414 This results in a straightforward re-use of the GMPLS Unified control 415 plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other 416 LSR currently manageable by a GMPLS-based control plane. 418 Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet 419 frame. 421 TAG 422 --------- 423 / \ 424 +-----------+------------+----+----+----+---------------+--------+ 425 | | | | | | | | 426 | MAC Dest | MAC Src |TPID|TCI |LEN\| Payload | FCS | 427 | Address | Address | | |Type| | | 428 | | | | | | | | 429 +-----------+------------+----+----+----+---------------+--------+ 431 Figure 5: Standard IEEE 802.1Q Frame Format 433 The TAG protocol Identifier (TPID) is a 16-bit length field which is 434 set a value of 0x88a8 to identify the frame as an IEEE 802.1ad tagged 435 frame. The TAG Control Information (TCI) is a 16-bit length field. 437 In this technique, the Ethernet label is encoded in the TCI field of 438 the S-VLAN TCI (see Figure 6). The length of the Ethernet label is 12 439 bits providing for a label space of 4k values per link. 441 S-VID translation is used in this technique. S-VID processing is 442 supported on most Ethernet switches. MAC address learning may be 443 inhibited, depending on the behavior of the forwarding entity. 445 Figure 6 depicts the S-VLAN TAG Control Information (TCI) 447 Oct: 1 2 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | PCP |D| VID | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 453 Figure 6: TCI Format 455 The Priority Code Point (PCP) is a 3-bit length field, which is used 456 to convey priority and drop eligibility parameters. This 3-bit field 457 refers to the 802.1p priority. 459 The PCP can be used in order to encode DiffServ parameters assuring 460 the DiffServ support for Ethernet LSP. In other words can be used as 461 the EXP filed of the MPLS shim header. 463 The D bit (1 bits) is the Drop Eligible Indicator (DEI) bit. 465 The VLAN Identifier (VID) is a 12-bit length field uniquely 466 identifying the VLAN to which the frame belongs. Its value can be 467 between 0 and 4.095. 469 3.1.2 Functional Behavior 471 When a frame/packet enters an ingress PE via a CE-PE interface, the 472 PE processes the incoming traffic flow by performing a number of pre- 473 processing operations on the frame. The pre-processing operations may 474 include, for example, VID translation, VID insertion/stripping, etc. 475 These operations are beyond the scope of this document. 477 The pre-processed frame is then presented to the ingress E-LER 478 function. The latter takes an incoming pre-processed frame, if 479 necessary adapts it to an Ethernet frame, adds an Ethernet label and 480 forwards it via the appropriate label-controlled interface over a 481 Ethernet point-to-point or point-to-multipoint LSP. 483 Throughout the GMPLS-controlled Ethernet network, Ethernet LSRs 484 switches labeled Ethernet frames via the appropriate interface based 485 on the ingress port and the S-VID Ethernet label, which is encoded in 486 the standard IEEE 802.1 frame header. The switching operation 487 replaces the S-VID Ethernet label before the frame is transmitted. 488 Frames that are received with an unknown S-VID Ethernet label are 489 silently discarded. The forwarding decision is based on the 490 information residing in the FIB. This table may be configured by the 491 GMPLS control plane. 493 The egress E-LER terminates the Ethernet LSP by removing the S-VID 494 label from incoming frames received on a label-controlled interface, 495 if necessary extracts the payload, and presents the frame for 496 appropriate post-processing operations. Post-processing may include, 497 for example, VID translation, VID insertion/ stripping, etc. These 498 operations are beyond the scope of this specification. The frame is 499 then appropriately forwarded towards its destination via the 500 appropriate label-controlled interface. 502 The S-VID Ethernet label is part of the Ethernet MAC frame header and 503 has link local scope. The same S-VID Ethernet label can be reused on 504 different interface. The coding of the S-VID Ethernet label does not 505 modify the format of the standard Ethernet frame, although it may add 506 new semantics to one or more fields. No modification is made to the 507 layers over which the Ethernet payload may be transmitted. 509 The S-VID Ethernet labels are assigned and interpreted locally and 510 have local significance. This does not preclude the assignment of the 511 same S-VID Ethernet label value by consecutive hops. The S-VID 512 Ethernet labels can be used for the establishment and the support 513 of Ethernet LSPs over multiple domains and for the support of point- 514 to-multipoint Ethernet LSPs) to carry Ethernet multicast traffic. 516 End-to-end Ethernet connectivity can be used to provide any service 517 that is supported by standard Ethernet. These services are mapped in 518 the Ethernet LERs to an appropriate Ethernet LSP. The Ethernet frame 519 is extended with the S-VID Ethernet label when it is sent over the 520 Ethernet LSP. With Ethernet services, the C-VID (included in the C- 521 TAG) may, as an option, be transmitted transparently over the 522 Ethernet LSP (i.e. preserved over the network), depending on the 523 service definition. 525 3.1.3 Control Plane 527 GMPLS signaling is used to configure the S-VIDs along the nodes 528 traversed by the Ethernet point-to-point or point-to-multipoint LSP. 530 The idea behind this solution is to prevent the control plane from 531 dealing with any MAC address space specifics such as to ensure 532 independence and transparency to the data plane addressing specifics. 533 GMPLS is used to configure the 12-bit S-VID label during Ethernet LSP 534 provisioning. 536 This results in a straightforward re-use of the GMPLS unified control 537 plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other 538 LSR currently manageable by a GMPLS-based control plane. 540 This technique may coexist with Ethernet bridging in the same network 541 or on the same network element. On the same port, GMPLS controlled 542 Ethernet label switching method and Ethernet bridging may coexist as 543 long as the S-VID space is configurable (to discriminate between the 544 switching and bridging ranges). A future work will be undertaken to 545 automate this configuration process using RSVP-TE protocol (for inst. 546 by extending the capability of the label set object). 548 3.2 Stacked VLAN TAGs (QinQ) Translation 550 3.2.1 Label Encoding 552 Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with 553 Stacked VLAN TAGs (QinQ). 555 S-TAG C-TAG 556 -------- ------- 557 / \ / \ 558 +----------+----------+----+----+----+----+----+---------------+---+ 559 | | | | | | | | | | 560 | MAC Dest | MAC Src |TPID|TCI |TPID|TCI |LEN\| Payload |FCS| 561 | Address | Address | | | | |Type| | | 562 | | | | | | | | | | 563 +----------+----------+----+----+----+----+----+---------------+---+ 565 Figure 7: Standard IEEE 802.1ad Format with Stacked VLAN. 567 In this technique the concatenation of the S-VID (i.e. the VID of the 568 S-TAG) and the C-VID (i.e. the VID of the C-TAG) is used as the 569 Ethernet label, resulting in a unique 24-bit length label. 571 This technique makes use of VID translation. Neither MAC learning nor 572 flooding for the range of VIDs are required. 574 3.2.2 Functional Behavior 576 The Stacked VLAN TAG translation functional behavior is the same as 577 the S-VID translation functional behavior (see Section 3.1.1), except 578 for the label space, which is wider (24 bits). For details about the 579 functional behavior, refer to section 3.1.1 above, replacing the term 580 'S-VID Ethernet label' with the term 'Stacked VLAN TAG Ethernet 581 label'. In cases where the 4.096 link local S-VID label space is too 582 small, the stacked VLAN Ethernet label can be used. 584 Note that when the stacked VLAN Ethernet label is used for the 585 Ethernet LSP, only a small address range belonging to the outer VLAN 586 tag has to be assigned to the GMPLS-controlled Ethernet Label 587 switching. The available VLAN range for bridging services is 588 therefore hardly affected, while the GMPLS-controlled Ethernet Label 589 switching can use the full address range of the inner tag. 591 3.2.3 Control Plane 593 The idea behind this solution is to prevent the control plane from 594 dealing with any MAC address space specifics such as to ensure 595 independence and transparency to the data plane addressing specifics. 596 GMPLS is used to configure the 24-bit label during Ethernet LSP 597 provisioning. 599 This results in a straightforward re-use of the GMPLS unified control 600 plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other 601 LSR currently manageable by a GMPLS-based control plane. 603 3.3 Concatenated VID/MAC Domain-wide labels 605 3.3.1 Label Encoding 607 In this technique, the concatenation of the VID (encoded in the TCI 608 immediately following the DA and SA MACs) and the Destination MAC 609 Address (DA MAC) is used as the Ethernet label, resulting in a unique 610 60-bit label. The VID can be a Q-TAG (Ethertype for TCI=0x8100), a 611 802.1ad S-TAG (Ethertype for TCI=0x8a88) or a 802.1ah B-TAG 612 (Ethertype TBD) depending on the network context. This technique 613 provides for a private sub-network labeling solution as the MAC 614 address space is "sub-network specific". This solution mandates 615 enforcement of unicast only traffic exchange for the specified (pre- 616 configured) VID range. 618 In order to use the unique 60-bit label, the normal mechanisms by 619 which Ethernet populates the forwarding table for the allocated range 620 of VIDs should be disabled, for example, MAC learning and flooding 621 are disabled for an allocated VID range, blocking is disabled, etc. 622 GMPLS is used to configure the 60-bit label. The control plane is 623 required to ensure loop freeness for the LSPs. 625 Note that having a label encoding technique which uses a network wide 626 label space definition requires that the support of the whole network 627 in this technique, even in case of multiple domains. 629 3.3.2 Functional Behavior 631 Invariant VID/MAC domain-wide labels are proposed such as to enable 632 reuse the IEEE 802.1 compliant hardware and forwarding and provide 633 VLAN independent point-to-point LSPs. Aspects of the profile used 634 are: 636 1) That the ether-relay filter database (forwarding tables) can be 637 configured with static entries by a management system or control 638 plane 639 2) That static entries are not tied to any internal forwarding 640 identifier (FID) or spanning tree 641 3) That Ethernet LSRs may be VLAN partitioned such that a unique 642 topology per VLAN is possible a.k.a. independent VLAN learning (IVL) 643 4) The ability to disable MAC learning by VLAN ID 644 5) The ability to disable spanning tree by VLAN ID 645 6) The MAC addressed interfaces in the Ethernet frame header are 646 provider owned addresses and not related to customer MAC 647 terminations. 648 7) The VLAN ID space is the provider administered VLAN ID space 650 A pre-provisioned portion of the VLAN ID set (referred to as the 651 connection-oriented Ethernet VLAN ID subset) is decoupled from the 652 IEEE 802.1 spanning tree, and the use of the VIDs in this subset is 653 confined to unicast forwarding to guard against configuration errors 654 such that any loop free constraint for the connection-oriented 655 Ethernet VLAN ID subset has been removed. This subset is available 656 across the whole GMPLS-controlled Ethernet domain. The topology for 657 each of the delegated VIDs corresponds to the complete physical mesh 658 of the Ethernet subnetwork, and unique connectivity instance (P2P or 659 MP2P multiplex) to each MAC address is possible per VID. 661 One way to think of the meaning of a VID out of the pre-provisioned 662 VLAN ID subset is as an instance identifier for unique connectivity 663 to the specified MAC. This permits a plurality of uniquely routed 664 paths up to the connection-oriented Ethernet VLAN ID subset size to 665 any given MAC. Although VIDs are nominally thought of as global 666 identifiers for a VLAN, for the purposes of labeled Ethernet frame 667 forwarding, they behave as single modifiers bound to the destination 668 MAC address. Since MAC addresses are unique with in the scope of the 669 connected network, the VID-MAC tuple becomes a unique 60-bit label 670 that can be destination administered (see Label Encoding). 672 The ability to multiplex paths traveling to the same destination is a 673 desirable property to conserve forwarding state. This creates MP2P 674 connectivity as a tree of P2P connections rooted at a destination. 675 These multiplexed paths share a common VID-DA-MAC tuple yet retain 676 the identity of the source due to the inclusion of the SA-MAC. The 677 SA-MAC may be interpreted at the end of the path for additional 678 operations or when capturing packets at other points on the paths. 679 This is a useful property from the point of view of OAM fault and 680 performance management at the expense of performing SA-MAC address 681 lookup on a per-interface basis. 683 This technique is designed such as to relax a number of constraints 684 for the routing of MP2P connectivity: 685 - maintains the Ethernet encoding of priority information per-packet 686 permitting an Ethernet analogy to E-LSPs 687 - requires uni-directional paths which share the same physical 688 resources but allows independent VID assignments. 689 - allows resource reservation independently in both directions. 691 Provisioned LSPs are identified from originating to terminating 692 provider MAC interface. The service offered to the end points of an 693 Ethernet "connection" configured as outlined above is the ability to 694 transport any payload that can be identified via Ethernet LLC 695 multiplexing. A non exhaustive list would be: 696 - client Ethernet MAC frames (802.1ah, under IEEE 802.1 definition) 697 - MPLS 698 - IP, IPX, etc. 700 This technique mandates enforcement of unicast only traffic exchange 701 for the specified (pre-configured) VID range. Meaning that server 702 layer multicast replication of client multicast traffic is not 703 supported, although client multicast traffic may still be 704 encapsulated and transported P2P using this technique. 706 3.3.3 Control plane 708 GMPLS is used for the control of the point-to-point paths. We 709 recognize the requirement for a single control plane to manage the 710 point-to-multipoint paths as well (for multicast traffic). However 711 such objective is outside the scope of this document. 713 Using this label encoding technique, a portion of the VLAN ID space 714 in an IVL capable switch is delegated to a control or management 715 plane. The control plane is used to directly populate the filter 716 database with (VID)-(DA-MAC)-(egress port) tuples to configure 717 unicast forwarding of Ethernet frames. A given (VID)-(DA-MAC) tuple 718 resolving to a single egress port on a Ethernet LSR, and a connection 719 being composed of a contiguous set of Ethernet LSRs configured this 720 way. 722 The goal of bringing the work to the IETF is to use GMPLS as the 723 unified GMPLS control plane for point to point LSPs. GMPLS can take 724 the role of the control plane that populates the Ether-relay filter 725 database. The following GMPLS extensions are foreseen for GMPLS 726 support: 727 - use of the upstream label object to establish bi-directional paths 728 - optional use of suggested label 729 - use of the association object for signaling of protection switched 730 paths 731 - definition of a new label object C-type for the VID-MAC tuple 732 label 734 4. Comparison 736 Two techniques are currently proposed as solutions for the GELS, 737 VID/DA MAC switching (using VID/DA MAC domain wide invariant labels) 738 and VID switching (using VID/stacked VID link local labels). 740 The former (see Section 3.3) makes use of a 60-bit domain-wide label 741 which is built from the concatenation of the 48-bit destination MAC 742 address of the provider edge node (DA B-MAC) and the 12-bit provider 743 VID (B-VID). This solution is referred to as solution 1. 745 The latter (see section 3.1 and 3.2) makes use of one of the 746 following local labels: the 802.1ad 12-bit S-VID, and the 24-bit 747 label which is created from the 802.1ad stacked VLAN (Q-in-Q). The 748 characteristics of a domain-wide label and of a local scope label are 749 described and analyzed in the GELS framework. This solution is 750 referred to as solution 2. 752 This section attempts to examine, analyze and compare the candidate 753 solutions which are described in Section 3 according to the criteria 754 listed in Section 2. Note that for both techniques, the analysis and 755 comparison assume the use of GMPLS for enabling the provisioning and 756 maintenance of the Ethernet LSPs, in both techniques. 758 Note also that the third solution class (MAC-only labels) may be 759 considered in future version of this document. 761 4.1 Ethernet P2P and P2MP TE LSPs 763 Both solutions provide for Connection Oriented Ethernet. In both 764 techniques the network is pre-configured with the connections and the 765 resources are allocated and preserved. In both techniques the traffic 766 flow is identified by a connection identifier (label). 768 Solution 1 handles unidirectional and bi-directional point-to-point 769 Traffic Engineered Ethernet LSPs. However, it does not handle 770 unidirectional point-to-multipoint Traffic Engineered Ethernet LSPs. 771 The VID space is dedicated to unicast purposes due to the IVL 772 capability, which is based on unicast forwarding corroding to the B- 773 VID/B-MAC tuple. Note that while in general, VID spaces should be 774 independent of the type of the traffic, here, the VID dedicated space 775 is enforced for unicast purposes. So, multicast traffic support is to 776 provided by the legacy connectionless Ethernet forwarding. 778 Solution 2 handles unidirectional and bi-directional point-to-point 779 Traffic Engineered Ethernet LSPs and unidirectional point-to- 780 multipoint Traffic Engineered Ethernet LSPs. 782 Both solutions enable Traffic Engineering to optimize the network 783 resource usage. 785 4.2 Ethernet LSP Merging and LSP Multiplexing 787 In Solution 1 due to the nature of the label which is constructed 788 from the DA B-MAC address and the B-VID, connections may be 789 multiplexed along the way to the destination. However, due to the 790 label structure there is no possibility to avoid data plane merging 791 that violates the end-to-end guaranteed BW per LSP. Although the 792 Ethernet encoding of priority information is reserved per-packet, the 793 end-to-end guaranteed bandwidth for a specific LSP can be violated 794 and used by other LSPs multiplexed into the same path (for example 795 with higher priority packets). In order to avoid Ethernet LSP 796 multiplexing and in order to guarantee end-to-end bandwidth per LSP a 797 different label should be assigned to each LSP (e.g. either a 798 different DA B-MAC address should be assigned to each LSP or a 799 different B-VID should be assigned to each LSP). 801 Solution 2 provides end-to-end QoS with guaranteed bandwidth and 802 controlled jitter and delay based on the service definition to 803 enforce the SLA. Solution 2 provides a simple method for 804 multiplexing: each Ethernet LSR should assign a unique label to each 805 particular source (label assigned on a per sender basis). 807 4.3 Services 809 In Solution 1, frames are mapped at the Ethernet LER to LSPs 810 according to the port on which the frames were received or according 811 to the outer VID. 813 In Solution 2, frames are mapped at the Ethernet LER to LSPs 814 according to the port on which the frames were received and the VID 815 of the outer VID. 817 Both solutions are capable to provide any connectivity service that 818 is supported by standard Ethernet encapsulation (such as IP/MPLS, 819 TDM, etc.). 821 The solutions are positioned as follows for what it concerns service 822 provisioning and maintenance: 824 o) In Solution 1, a pool of unique MAC addresses and a range of VIDs 825 should be configured at the provider Ethernet LER. LERs should also 826 manage VID/MAC address relation. The label has a domain wide 827 significance. Any modification to a label or addition of a new label 828 is circulated across the network. 830 In Solution 2, only a range of VIDs that should be used for switching 831 purposes technique should be configured at each Ethernet LSR. When an 832 Ethernet LSP is provisioned across the network, each node along the 833 path arbitrarily allocates a free label for the LSP. The label has 834 only link local significance. 836 o) Both solutions provide network trunks (nesting LSPs) in order to 837 simplify the delivery of services across the network. Theoretically 838 the number of services that may be transmitted within the tunnels is 839 unlimited. 841 o) Both solutions employ OAM and provide a means to minimize the 842 number of LSPs to be monitored. Only network trunks should be 843 actively monitored. Services may be monitored according to specific 844 service requirements. 846 With Solution 2 (12-bit), up to 4K tunnels may be provisioned per 847 port. Within each port up to 4K services can be delivered. With 848 Solution 2 (24-bit), up to 16M tunnels may be provisioned per port. 849 Other combinations are possible as well. Using this solution, LSPs 850 can also be used to deliver services (with no tunneling). This 851 capability has a benefit in particular network scenarios, where there 852 is no need for the overhead of tunnel provisioning and superfluous 853 encapsulation. 855 4.4 OAM 857 Solution 1 requires unicast CC OAM messages which are currently not 858 defined or implemented. Moreover, when using this solution, the SA- 859 MAC can be captured at intermediate Ethernet LSRs or at the egress 860 Ethernet LER to detect misconnectivity where traffic from one LSP is 861 leaked into another LSP. Note that misconnectivity can occur due to 862 misconfigurations. 864 Solution 2 enables the support of OAM (IEEE 802.1ag) messages, to 865 ensure the correct operation of the network. CC OAM frames are 866 transmitted within the LSP and will reach their destination. Each LSP 867 is identified by an end-to-end connection identifier (5-tuple). The 868 customer's information may be interpreted to detect misconnectivity. 869 OAM messages are sent along the path to detect failures or problems 870 in the network. 872 4.5 Resiliency 874 Both Solutions provide mechanisms for matching the sub 50 ms failover 875 times required for maintaining time-bounded services. 877 Due to the domain-wide nature of the label used in Solution 1, 878 certain recovery mechanisms that are provided by the GMPLS can not be 879 applied in case of domain-wide VID/MAC label (e.g. 1:1 fast reroute 880 which apply two different labels for the protected and the detour 881 LSPs, etc.). 883 In case of LSPs over multiple domains (i.e. inter-domain), Solution 1 884 can not protect against a failure of an edge node (which connects to 885 other domains). This is true for each of the three recovery 886 techniques (unless dual homing is supported, but this complicated 887 solution should be proven to work). 889 Solution 2 supports all three LSP recovery techniques: global (end- 890 to-end), segment and local. This solution provides mechanism to 891 protect against any failure in the network (including failure of 892 boundary nodes in case of an inter-domain operation). 894 4.6 Inter-domain 896 Both solutions enable the provisioning Ethernet LSPs across multiple 897 domains (inter-domain). Both techniques support the peering and the 898 client/server interconnection modes. 900 In Solution 1, when peering is supported, the network trunk is 901 terminated at the edge of a domain. The services may be processed 902 according to one of the following VIDs: C-VID, or S-VID or I-SID. The 903 I-SID may be translated to S-TAG, limiting to 4094 service instances 904 across an E-NNI. It may be translated to a DMZ value, limiting to 905 2**24 service instances across an E-NNI. In any case, note that as 906 the 802.1ah is not final yet, the I-SID processing is not defined. 908 The [CCAMP-ID-FRM] defines three options for signaling TE LSPs across 909 multiple domains, as follows: LSP nesting (client/server mode), 910 contiguous LSP (peering mode) and LSP stitching (peering mode). 912 In Solution 1, the contiguous LSP option will probably not be 913 supported because of the domain-wide nature of the label. If 914 supported, the carriers' would have to offer each other globally 915 unique label. In such a case, the label would come from each 916 carrier's administrative space (MAC address of the terminating 917 interface). 919 In Solution 2, all the three signaling options are supported. 921 4.7 Scalability 923 4.7.1 MAC Address 924 Both solutions disable MAC learning for the VID range that is 925 supported for connection-oriented Ethernet purposes. Thus, the flush 926 FIB operation associated with topology change and flooding 927 operations, which leads to slow recovery and convergence, is 928 eliminated. 930 The switching operation in both techniques is independent of the 931 destination subscriber MAC address. 933 4.7.2 VLAN ID (VID) 935 In Solution 1, the VID in conjunction to the DA B-MAC is used as 936 domain-wide label. As specified above, in order to avoid the LSP 937 multiplexing and guarantee end-to-end BW per LSP, a different label 938 should be assigned to each LSP. Hence, either a different B-VID or a 939 different DA B-MAC address should be assigned to each LSP between a 940 particular pair of source and destination Ethernet LERs. In case of a 941 different DA B-MAC address, it requires the provisioning of a pool of 942 MAC addresses per pair (source and destination) of Ethernet LERs 943 dependent on the required number of LSPs that should be provisioned 944 between this pair of Ethernet LERs. In case of a different B-VID, it 945 violates the VLAN scalability. The space of the VID is limited per 946 node and a certain range of VIDs should be assigned to the bridging 947 function (in order to provide for example multicast services, etc.). 949 In Solution 2, the VID label has link local significance and can be 950 reused on different interface (per interface label spaces similar to 951 ATM�s VCI/VPI or MPLS�s label space). The label space can reach a 952 maximum of 4K VIDs per port if the 12_bit S-VID labels is used and a 953 maximum of 16M VIDs if 24-bit labels are used. 955 4.7.3 Ethernet Frame Switching 957 Both solutions do not rely on the customers' destination MAC 958 addresses. 960 4.7.4 Label 962 Both solutions encode the Ethernet label as part of the Ethernet MAC 963 frame header. 965 Solution 1 makes use of the 802.1ah frame format: 48 bits SA B-MAC 966 address, 48 bits DA B-MAC address, 32 bits B-TAG and 24-bit I-SID. 967 The label being a combination of the DA B-MAC and the B-VID is 60- 968 bits long. 970 Solution 2 makes use of the 802.1ad frame format. This requires a 32- 971 bit S-TAG to encode the S-VID label or 64-bit S-TAG + C-TAG to encode 972 the extended the 24-bit label (composed by the S-VID and C-VID). 974 In solution 1, the label space has a 60-bit length and has a domain 975 wide significance. The implication on the number of LSPs that can be 976 provisioned in the network is not trivial. Theoretically, this number 977 is 2^60. Practically, this requires a tedious provisioning effort. 978 Depending on the connectivity, a varying set of MAC addresses should 979 be manually configured. 981 In solution 2, the number of LSPs that can be provisioned depends on 982 the label type. With S-VIDs, up to 4K LSPs per port can be 983 provisioned. With 24-bit labels up to 16M LSPs per port can be 984 provisioned. 986 In addition, the label length and space size also affects the 987 implementation of the FID's lookup table. In Solution 1, the key to 988 the lookup table is 60-bits long. In Solution 2, it is either 12-bits 989 or 24-bits long. 991 4.7.5 LSP Hierarchy 993 TBD. 995 4.8 Backward compatibility with IEEE 802.1 997 Both label encoding techniques make use of the structure of the 998 standard IEEE 802.1 Ethernet frame. Both solutions do not modify the 999 format of the standard Ethernet frame, but do add new semantics to 1000 one or more fields. 1002 4.9 Applicability 1004 1) Metro access and Metro aggregation networks 1006 The Metro access and the metro aggregation networks by nature are 1007 small networks which are characterized by having a small number of 1008 nodes deployed at the network. The role of that metro access/metro 1009 aggregation network is to provide connectivity between a user and a 1010 service platform (e.g. BRAS, edge router, etc.). 1012 Employing Solution 1 in such environment adds a lot of overhead in 1013 the network (e.g. MAC encapsulation), and increases CAPEX, without 1014 apparent benefits. The idea behind this solution is to increase CAPEX 1015 at the edge of the network in order to reduce CAPEX at the core of 1016 the network. In typical Metro access/Metro aggregation networks there 1017 are hardly any core routers (if at all) while there are many edge 1018 nodes. 1020 In addition, both DSLAMs and BRAS do not handle IEEE 802.1ah frames. 1021 They are only capable of extracting/adding one or two VLAN TAGs. It 1022 is thus appropriate to make use of these VLAN TAGs and perform VID 1023 switching using the same encapsulation than those provided by the 1024 DSLAM and the BRAS. Solution 2 is more appropriate for residential 1025 services, where the BRAS handle the two VLAN TAGs, which identify the 1026 customer. Hence, Solution 2 is more suitable for metro access/metro 1027 aggregation networks than Solution 1. 1029 2) Metro-core 1031 The metro core is a larger network and its role is to connect several 1032 metro access/metro aggregation networks. 1034 Both Solutions can be deployed at the metro-core networks. Both 1035 provide connection-oriented Ethernet with tunneling mechanisms. The 1036 selection of the specific technique that should be deployed should be 1037 based on the solution analysis described in this document. 1039 3) Core and Transport networks 1041 Same observation as for Metro-core applies. 1043 4.10 Security 1045 In both techniques the number of network entry points is reduced. 1046 Policing and filtering are provided on the provider edge nodes. Some 1047 mechanisms may be provided at the network edges to rate limit the 1048 amount of traffic that can be transmitted into a given Ethernet LSP. 1050 Solution 1 switches on MAC addresses hence mandating the use of MAC- 1051 in-MAC encapsulation to resolve issues associated with MAC addresses. 1053 Solution 2 inherently eliminates security issues on MAC addresses 1054 (MAC spoofing and MAC attack) because it is agnostic to MAC 1055 addresses. 1057 Both solutions eliminate security issues associated with VLAN TAGs. 1058 At the provider edge, customers are attached to the provider network 1059 via particular VLANs on a particular port. Frames with other VLANs 1060 will be blocked. Across the network, only the VLAN Identifier(s) 1061 added by the provider edge node is/are inspected. Any other nested 1062 VLAN has no meaning across the provider network. 1064 5. Conclusion 1066 The proposed solutions have been analyzed and compared according to 1067 the criteria, which were defined for this purpose. 1069 According to the analysis, the solution that better complies to the 1070 GELS requirements, as well as better addresses the GELS motivations 1071 and objectives should be identifiable. 1073 It may be that different solutions have to be selected for example to 1074 satisfy different network scenarios or/and different applications. In 1075 such a case, a specific label encoding technique should be selected 1076 according to the capability of the GMPLS-enabled Ethernet network 1077 element and/or the capability of the label-controlled Ethernet 1078 interface. Hence, leaving the possibility for adopting different 1079 solutions for GELS. It may also be that the solutions complement each 1080 other, and for example should be deployed in different network areas. 1082 In any case, it is recommended that the GELS define an extensible 1083 solution which will leave room for future definitions, especially 1084 since the Carrier Grade Ethernet solution is currently under 1085 investigation by service providers. 1087 Please comment on the mailing list. 1089 7. References 1091 7.1. Normative References 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 1097 V., and G. Swallow, "RSVP-TE: Extensions to RSVP 1098 for LSP Tunnels", RFC 3209, December 2001. 1100 [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in 1101 Resource ReSerVation Protocol - Traffic Engineering 1102 (RSVP-TE)", RFC 3477, January 2003. 1104 [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to 1105 OSPF Version 2", RFC 3630, September 2003. 1107 [RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate 1108 System (IS-IS) Extensions for Traffic 1109 Engineering (TE)," RFC 3784, June 2004. 1111 [RFC3471] Berger, L., "Generalized Multi-Protocol Label 1112 Switching (GMPLS) Signaling Functional Description", 1113 RFC 3471, January 2003. 1115 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 1116 Switching (GMPLS) Signaling Resource ReserVation 1117 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1118 RFC 3473, January 2003. 1120 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label 1121 Switching (GMPLS) Architecture", RFC 3945, October 1122 2004. 1124 7.2. Informative References 1126 [MRN-REQ] K.Shiomoto et al., "Requirements for GMPLS-based 1127 Multi-Region Networks (MRN)", Work in Progress, draft- 1128 ietf-ccamp-gmpls-mrn-reqs-00.txt. 1130 8. Acknowledgments 1132 9. Author's Addresses 1134 Dimitri Papadimitriou 1135 Alcatel 1136 Francis Wellesplein 1, 1137 B-2018 Antwerpen, Belgium 1138 Phone: +32 3 2408491 1139 Email: dimitri.papadimitriou@alcatel.be 1141 Nurit Sprecher 1142 Siemens AG (Seabridge Networks) 1143 3 Hanagar St. Neve Ne'eman B 1144 Hod Hasharon, 45241 Israel 1145 Email: nurit.sprecher@seabridgenetworks.com 1147 Jaihyung Cho 1148 Electronics and Telecommunications Research Institute (ETRI) 1149 161 Gajung-dong, Yuseong-gu 1150 Daejeon 305-350, Korea 1151 Phone: +82 42 860 5514 1152 Email: jaihyung@etri.re.kr 1154 Loa Andersson 1155 Acreo AB 1156 Email: loa@pi.se 1158 Attila Tak�cs 1159 Traffic Lab, Ericsson Research 1160 Ericsson Hungary Ltd. 1161 Laborc 1. 1162 Budapest, Hungary, H-1037 1163 Email: attila.takacs@ericsson.com 1165 Don Fedyk 1166 Nortel Networks 1167 600 Technology Park 1168 Billerica, Massachusetts 1169 01821 U.S.A 1170 Phone: +1 (978) 288 3041 1171 Email: dwfedyk@nortel.com 1173 Dave Allan 1174 Nortel 1175 3500 Carling Ave. 1176 Ottawa, Ontario 1177 K1Y 4H7 1178 Phone: (613) 763-6362 1179 Email: dallan@nortel.com 1181 Full Copyright Statement 1183 Copyright (C) The Internet Society (2006). 1185 This document is subject to the rights, licenses and restrictions 1186 contained in BCP 78, and except as set forth therein, the authors 1187 retain all their rights. 1189 This document and the information contained herein are provided on an 1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1192 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1193 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1194 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1197 Intellectual Property 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at ietf- 1219 ipr@ietf.org.