idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 169: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 170: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 173: '...-TP control pane MUST support the conf...' RFC 2119 keyword, line 176: '.... OAM functions SHOULD be configurabl...' RFC 2119 keyword, line 196: '... operator MUST be able to configure ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 23, 2008) is 5602 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: 'RFC4379' is mentioned on line 118, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC3469' is defined on line 520, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GELS-Framework' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-CFM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-PBBTE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-FWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-OAM-REQ' ** Downref: Normative reference to an Informational RFC: RFC 3469 ** Downref: Normative reference to an Informational RFC: RFC 4377 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Fedyk 5 Expires: June 26, 2009 Nortel 6 H. Jia 7 Huawei 8 December 23, 2008 10 OAM Configuration Framework and Requirements for GMPLS RSVP-TE 11 draft-ietf-ccamp-oam-configuration-fwk-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 26, 2009. 36 Copyright Notice 38 Copyright (c) 2008 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 OAM functions are essential to ensure that the desired service level 51 of traffic engineered connections are met. In certain technologies 52 OAM entities are inherently established once the connection is set 53 up. However other technologies, especially OAM for packet switched 54 networks, require an extra configuration step after connection 55 establishment to setup OAM entities. This document specifies 56 extensions to RSVP-TE to support the establishment and configuration 57 of OAM entities along with LSP signalling. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9 70 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9 71 3.2. OAM entities desired -- LSP Attributes flag . . . . . . . 10 72 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 73 3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 11 74 3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 12 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 16 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 1. Introduction 84 Operations and Management (OAM) functions are essential to ensure 85 that the desired service level of traffic engineered connections are 86 met. OAM functions ease network operation by reducing complexity, 87 enhance network survivability, verify network performance, and in 88 turn reduce operational costs. 90 In certain technologies OAM entities are inherently established once 91 the connection is set up. However other technologies, especially OAM 92 for packet switched networks, require an extra configuration step 93 after connection establishment to setup OAM entities. 95 In some situations the use of OAM functions, like those of Fault- 96 (FM) and Performance Management (PM), may be optional confirming to 97 actual network management policies. Hence the network operator must 98 be able to choose which kind of OAM functions to apply to specific 99 connections and with what parameters the selected OAM functions 100 should be configured and operated. To achieve this objective OAM 101 entities and specific functions must be selectively configurable. 103 The GMPLS control plane consists of a set of protocols: OSPF-TE, 104 RSVP-TE and LMP. which are used to reduce manual configuration and 105 improve management efficiency. RSVP-TE is used to setup and 106 configure end-to-end connections. A new useful application of 107 RSVP-TE is OAM configuration and control for transport networks. 109 When RSVP-TE is used for LSP establishment it is desirable to bind 110 OAM setup to connection establishment signalling to avoid two 111 separate management/configuration steps (connection setup followed by 112 OAM configuration) which increases delay, processing and more 113 importantly may be prune to misconfiguration errors. 115 The mechansim described in this document provides an additional 116 option for bootstrapping OAM that is not intended to replace or 117 deprecate the use of other OAM bootstrapping techniques such as LSP 118 Ping [RFC4379]. The procedures specified in this document are 119 intended only for use in environments where RSVP-TE signaling is 120 already in use to set up the LSPs that are to be monitored using OAM. 122 This document describes requirements on OAM configuration and control 123 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 124 providing a framework to configure and control OAM entities along 125 with capability to carry technology specific information. Extensions 126 can be grouped into generic elements that are applicable to any OAM 127 solution and technology specific elements that provide additional 128 configuration parameters only needed for a specific OAM technology. 129 This document specifies the technology agnostic elements that alone 130 can be used to establish OAM entities in the case no technology 131 specific information is needed, and specifies the way additional 132 technology specific OAM parameters are provided. 134 2. Requirements 136 MPLS OAM requirements are described in [RFC4377]. It provides 137 requirements to create consistent OAM functionality for MPLS 138 networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The 139 GMPLS OAM requirements are based on the MPLS OAM requirements 140 [RFC4377], in addition it also considers the existing OAM techniques 141 in non-packet networks. 143 The following list is an excerpt of MPLS OAM requirements documented 144 in [RFC4377]. Only a few requirements are discussed that bear a 145 direct relevance to the discussion set forth in this document. 147 o It is desired to support the automation of LSP defect detection. 148 It is especially important in cases where large numbers of LSPs 149 might be tested. 151 o In particular some LSPs may require automated ingress-LSR to 152 egress-LSR testing functionality, while others may not. 154 o Mechanisms are required to coordinate network responses to 155 defects. Such mechanisms may include alarm suppression, 156 translating defect signals at technology boundaries, and 157 synchronising defect detection times by setting appropriately 158 bounded detection timeframes. 160 MPLS-TP defines a profile of MPLS targeted at transport applications 161 [MPLS-TP-FWK]. This profile specifies the specific MPLS 162 characteristics and extensions required to meet transport 163 requirements, including providing additional OAM, survivability and 164 other maintenance functions not currently supported by MPLS. 165 Specific OAM requirements for MPLS-TP are specified in 166 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 167 to configure and control OAM entities. 169 o The use of OAM functions SHOULD be optional for the operator. A 170 network operator SHOULD be able to choose which OAM functions to 171 use and which Maintenance Entity to apply them to. 173 o The MPLS-TP control pane MUST support the configuration and 174 modification of OAM maintenance points as well as the activation/ 175 deactivation of OAM when the transport path is established or 176 modified. OAM functions SHOULD be configurable as part of 177 connectivity (LSP or PW) management. 179 Ethernet Connectivity Fault Management (CFM) defines an adjunct 180 connectivity monitoring OAM flow to check the liveliness of Ethernet 181 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 182 support explicitly-routed Ethernet connections. CFM can be used to 183 track the liveliness of PBB-TE connections and detect data plane 184 failures. In IETF the GMPLS controlled Ethernet Label Switching 185 (GELS) [GELS-Framework] work is extending the GMPLS control plane to 186 support the establishment of point-to-point PBB-TE data plane 187 connections. Without control plane support separate management 188 commands would be needed to configure and start CFM. 190 GMPLS based OAM configuration and control should be general to be 191 applicable to a wide range of data plane technologies and OAM 192 solution. There are three typical data plane technologies used for 193 transport application, which are wavelength based such as WSON, TDM 194 based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] 195 and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the 196 operator MUST be able to configure and control the following OAM 197 functions. 199 o It MUST be possible to explicitly request the setup of OAM 200 entities for the signalled LSP and provide specific information 201 for the setup if this is required by the technology. 203 o When periodic messages are used for liveliness check (continuity 204 check) of LSPs it MUST be possible to set the frequency of 205 messages allowing proper configuration for fulfilling the 206 requirements of the service and/or meeting the detection time 207 boundaries posed by possible congruent connectivity check 208 operations of higher layer applications. For a network operator 209 to be able to balance the trade-off in fast failure detection and 210 overhead it is beneficial to configure the frequency of continuity 211 check messages on a per LSP basis. 213 o Control of alarms is important to avoid false alarm indications 214 and reporting to the management system. It MUST be possible to 215 enable/disable alarms generated by OAM functions. In some cases 216 selective alarm control may be desirable when, for instance, the 217 operator is only concerned about critical alarms thus the non- 218 service affecting alarms should be inhibited. 220 o Performance Monitoring (PM) is continuously collecting information 221 about specific characteristics of the connection. It MUST be 222 possible to configure PM functions, e.g., set monitoring intervals 223 and thresholds for PM initiated alarms. For consistent 224 measurement of Service Level Agreements (SLAs) it may be required 225 that measurement points agree on a common probing rate to avoid 226 measurement problems. 228 o The extensions must allow the operator to use only a minimal set 229 of OAM configuration and control features if the data plane 230 technology, the OAM solution or network management policy allows. 231 The extensions must be reusable as much as reasonably possible. 232 That is generic OAM parameters and data plane or OAM technology 233 specific parameters must be separated. 235 3. GMPLS RSVP-TE Extensions 237 3.1. Operation overview 239 Two types of Maintenance Poits (MPs) are distinguished: Maintenance 240 End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs 241 are located at the ends of an LSP and are capable of initiating and 242 terminating OAM packets for Fault Management (FM) and Performance 243 Monitoring (PM). MIPs on the other hand are located at transit nodes 244 of an LSP and are capable of reacting to some OAM packets but 245 otherwise do not initiate packets. Maintenance Entity (ME) refers to 246 an association of MEPs and MIPs that are provisioned to monitor an 247 LSP. The ME association is achieved by configuring MPs of an ME with 248 the same unique ME ID. Each MEP must have unique identification (MEP 249 ID) within the ME. 251 When an LSP is signalled forwarding association is established 252 between endpoints and transit nodes via label bindings. This 253 association creates a context for the OAM entities monitoring the 254 LSP. On top of this association OAM entities may be configured with 255 an ME ID and MEP IDs. The ME ID may be used to detect 256 misconfiguration errors and leacking OAM traffic. Within the ME the 257 MEP ID can be used to demultiplex and identify the originating MEP of 258 OAM packets. Since MIPs do not originate OAM packets no specific 259 configuration is required for them. 261 In addition to the ME and MEP identification parameters pro-active 262 OAM functions (e.g., Continuity Check (CC), Performance Monitoring) 263 may have specific parameters requiring configuration as well. In 264 particular, the frequency of periodic CC packets and the measurement 265 interval for loss and delay measurements may need to be configured. 267 MEP 268 +-------------+ 269 |OAM Functions| 270 | FM | PM | 271 +------+------+ 272 | MEP ID | 273 +-------------+ 274 | ME ID | 275 +-------------+ 276 +-------------+ 277 | LSP | 278 +-------------+ 280 In some cases all the above parameters may be either derived form 281 some exiting information or pre-configured default values can be 282 used. In the simplest case the control plane needs to provide 283 information whether or not a ME with MPs need to be setup for the 284 signalled LSP. If OAM entities are created signalling must provide 285 means to activate/deactivate OAM message flows and associated alarms. 287 ME and MEP IDs as well as configuration of OAM functions are 288 technology specific, i.e., vary depending on the data plane 289 technology and the chosen OAM solution. In addition for any given 290 data plane technology a set of OAM solutions may be applicable. The 291 OAM configuration framework allows selecting a specific OAM solution 292 to be used for the signalled LSP and provides technology specific 293 TLVs to carry further detailed configuration information. 295 3.2. OAM entities desired -- LSP Attributes flag 297 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 298 indicate options and attributes of the LSP. The Flags field has 8 299 bits and hence is limited to differentiate only 8 options. [RFC4420] 300 defines a new object for RSVP-TE messages to allow the signalling of 301 arbitrary attribute parameters making RSVP-TE easily extensible to 302 support new applications. Furthermore, [RFC4420] allows options and 303 attributes that do not need to be acted on by all Label Switched 304 Routers (LSRs) along the path of the LSP. In particular, these 305 options and attributes may apply only to key LSRs on the path such as 306 the ingress LSR and egress LSR. Options and attributes can be 307 signalled transparently, and only examined at those points that need 308 to act on them. The LSP_ATTRIBUTES object and the 309 LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide 310 means to signal LSP attributes and options in the form of TLVs. 311 Options and attributes signalled in the LSP_ATTRIBUTES object can be 312 passed transparently through LSRs not supporting a particular option 313 or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES 314 object must be examined and processed by each LSR. One TLV is 315 defined in [RFC4420]: the Attributes Flags TLV. 317 A new bit (10 IANA to assign): "OAM entities desired" is allocated in 318 the LSP Attributes Flags TLV. If the "OAM entities desired" bit is 319 set it is indicating that the establishment of OAM entities are 320 required at the endpoints of the signalled LSP. If the establishment 321 of OAM entities is not supported an error must be generated: "OAM 322 Problem/OAM establishment not supported". 324 If the "OAM entities desired" bit is set and additional parameters 325 are needed to configure the OAM entities an OAM Configuration TLV may 326 be included in the LSP_ATTRIBUTES object. 328 3.3. OAM Configuration TLV 330 This TLV specifies which OAM technology/method should be used for the 331 LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES 332 object in Path messages. 334 0 1 2 3 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type (2) (IANA) | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | OAM Type | OAM Function | Reserved (set to all 0s) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 343 assign). 345 OAM Type: specifies the technology specify OAM method. If the 346 requested OAM method is not supported an error must be generated: 347 "OAM Problem/Unsupported OAM Type". 349 This document defines no types. The receiving node based on the OAM 350 Type will check if a corresponding technology specific OAM 351 configuration TLV is included. 353 OAM Function Flags: specifies proactive OAM functions (e.g., 354 connectivity monitoring, loss and delay measurement) that should be 355 established and configured. If the selected OAM Function(s) is(are) 356 not supported an error must be generated: "OAM Problem/Unsupported 357 OAM Function". 359 This document defines the following flags. 361 OAM Function Flag Description 362 --------------------- --------------------------- 363 0 Connectivity Monitoring 364 1-7 Reserved 366 3.4. Monitoring Disabled - Admin_Status bit 368 Administrative Status Information is carried in the ADMIN_STATUS 369 Object. The Administrative Status Information is described in 370 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 371 [RFC3473]. 373 One bit is allocated for the administrative control of OAM 374 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 375 occupied (assigned by IANA or temporarily blocked by work in progress 376 Internet drafts). As the 24th bit (IANA to assign) this draft 377 introduces the Monitoring Disabled (M) bit. When this bit is set the 378 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no 379 continuity check messages are sent). 381 3.5. OAM configuration errors 383 To handle OAM configuration errors a new Error Code (IANA to assign) 384 "OAM Problem" is introduced. To refer to specific problems a set of 385 Error Values is defined. 387 If a node does not support the establishment of OAM entities via 388 RSVP-TE signalling it must use the error value (IANA to assign): "OAM 389 establishment not supported" in the PathErr message. 391 If a node does not support a specific OAM technology/solution it must 392 use the error value (IANA to assign): "Unsupported OAM Type" in the 393 PathErr message. 395 If a node does not support a specific OAM Function it must use the 396 error value (IANA to assign): "Unsupported OAM Function" in the 397 PathErr message. 399 4. IANA Considerations 401 One bit (Monitoring Disabled (M)) needs to be allocated in the 402 ADMIN_STATUS Object. 404 One bit ("OAM entities desired") needs to be allocated in the LSP 405 Attributes Flag Registry. 407 This document specifies one new TLVs to be carried in the 408 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: 409 OAM Configuration TLV. 411 One new Error Code: "OAM Problem" and three new values: "OAM 412 establishment not supported", "Unsupported OAM Type" and "Unsupported 413 OAM Function" needs to be assigned. 415 5. Security Considerations 417 The signalling of OAM related parameters and the automatic 418 establishment of OAM entities introduces additional security 419 considerations to those discussed in [RFC3473]. In particular, a 420 network element could be overloaded, if an attacker would request 421 liveliness monitoring, with frequent periodic messages, for a high 422 number of LSPs, targeting a single network element. 424 Security aspects will be covered in more detailed in subsequent 425 versions of this document. 427 6. Acknowledgements 429 The authors would like to thank Francesco Fondelli, Adrian Farrel, 430 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 431 comments. 433 Appendix A. Discussion on alternatives 435 This appendix summarises the discussions after IETF-71 about the way 436 OAM configuration information should be carried in RSVP-TE. 438 The first question is how the requirement for OAM establishment is 439 signalled and how the operation of OAM is controlled. There is a 440 straightforward way to achieve these using existing objects and 441 fields: 443 o Use one or more OAM flags in the LSP Attributes Flag TLV within 444 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 445 OAM entities for the LSP need to be established. If for any 446 reason this cannot be done a notification is sent or an error is 447 raised. 449 o Once the LSP with the desired OAM entities is established OAM 450 operation may be controlled using one or more flags in the 451 ADMIN_STATUS object. For instance, the generation of connectivity 452 monitoring messages can be disabled/enabled by setting/clearing a 453 flag in the ADMIN_STATUS object. 455 However, there are two alternatives when it comes to signalling the 456 actual configuration parameters of OAM entities. 458 o Extension of the LSP_ATTRIBUTES object with new TLVs. 460 o Definition of a new RSVP-TE object to carry OAM information. 462 In the first case, a new OAM configuration TLV is defined in the 463 LSP_ATTRIBUTES object. This TLV would provide the detailed 464 information needed for LSPs with a set OAM flag in the LSP Attributes 465 Flag TLV. The rationale for this approach is that in addition to 466 setting flags the LSP_ATTRIBUTES object may carry complementary 467 information for all or some of the flags set. Furthermore, as top 468 level RSVP-TE objects may become scarce resources, it seems to be 469 beneficial not to allocate new RSVP-TE objects for the purpose of 470 providing detailed information for new LSP Attribute Flags. 471 Currently there is only one TLV, the Attributes Flag TLV, defined in 472 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 473 the flags would make a precedence and possibly be a guideline for 474 similar future extensions. 476 The other alternative would be to allocate a dedicated object for OAM 477 configuration information. The rationale for this is that the 478 complex information that may be required for OAM configuration would 479 unnecessarily add complexity to LSP_ATTRIBUTES/ 480 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 482 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 483 carry configuration information of data plane entities, thus a new 484 object like an "OAM_SPEC" may be a better fit to existing protocol 485 elements. 487 The authors of this document favour the first alternative (adding new 488 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 489 alternative to select for standardisation is up for the working group 490 to decide. In any case, the information to be carried would be the 491 same or very similar for both alternatives. 493 7. References 495 [GELS-Framework] 496 "GMPLS Ethernet Label Switching Architecture and 497 Framework", Internet Draft, work in progress. 499 [GMPLS-OAM] 500 "OAM Requirements for Generalized Multi-Protocol Label 501 Switching (GMPLS) Networks", Internet Draft, work in 502 progress. 504 [IEEE-CFM] 505 "IEEE 802.1ag, Draft Standard for Connectivity Fault 506 Management", work in progress. 508 [IEEE-PBBTE] 509 "IEEE 802.1Qay Draft Standard for Provider Backbone 510 Bridging Traffic Engineering", work in progress. 512 [MPLS-TP-FWK] 513 "A Framework for MPLS in Transport Networks", Internet 514 Draft, work in progress. 516 [MPLS-TP-OAM-REQ] 517 "Requirements for OAM in MPLS Transport Networks", 518 Internet Draft, work in progress. 520 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 521 Recovery", RFC 3469, February 2003. 523 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 524 Signaling Functional Description", RFC 3471, January 2003. 526 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 527 Signaling Resource ReserVation Protocol-Traffic 528 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 530 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 531 Protocol Label Switched (MPLS) Networks", RFC 4377, 532 February 2006. 534 [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching 535 (MPLS) Label Switched Path (LSP) Establishment Using 536 Resource ReserVation Protocol-Traffic Engineering 537 (RSVP-TE)", RFC 4420, February 2006. 539 Authors' Addresses 541 Attila Takacs 542 Ericsson 543 Laborc u. 1. 544 Budapest, 1037 545 Hungary 547 Email: attila.takacs@ericsson.com 549 Don Fedyk 550 Nortel 551 600 Technology Park Drive 552 Billerica, MA 01821 553 USA 555 Email: dwfedyk@nortel.com 557 He Jia 558 Huawei 560 Email: hejia@huawei.com