idnits 2.17.1 draft-takacs-ccamp-oam-configuration-fwk-01.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, updated by RFC 4748 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. 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 153: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 154: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 157: '...-TP control pane MUST support the conf...' RFC 2119 keyword, line 160: '.... OAM functions SHOULD be configurabl...' RFC 2119 keyword, line 180: '... operator MUST be able to configure ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 3, 2008) is 5651 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) == Unused Reference: 'RFC3469' is defined on line 504, 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: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 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: May 7, 2009 Nortel 6 H. Jia 7 Huawei 8 November 3, 2008 10 OAM Configuration Framework and Requirements for GMPLS RSVP-TE 11 draft-takacs-ccamp-oam-configuration-fwk-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 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 This Internet-Draft will expire on May 7, 2009. 38 Abstract 40 OAM functions are essential to ensure that the desired service level 41 of traffic engineered connections are met. In certain technologies 42 OAM entities are inherently established once the connection is set 43 up. However other technologies, especially OAM for packet switched 44 networks, require an extra configuration step after connection 45 establishment to setup OAM entities. This document specifies 46 extensions to RSVP-TE to support the establishment and configuration 47 of OAM entities along with LSP signalling. 49 Requirements Language 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 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 8 60 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 8 61 3.2. OAM entities desired -- LSP Attributes flag . . . . . . . 9 62 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 10 63 3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 10 64 3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 11 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 68 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 15 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 73 1. Introduction 75 Operations and Management (OAM) functions are essential to ensure 76 that the desired service level of traffic engineered connections are 77 met. OAM functions ease network operation by reducing complexity, 78 enhance network survivability, verify network performance, and in 79 turn reduce operational costs. 81 In certain technologies OAM entities are inherently established once 82 the connection is set up. However other technologies, especially OAM 83 for packet switched networks, require an extra configuration step 84 after connection establishment to setup OAM entities. 86 In some situations the use of OAM functions, like those of Fault- 87 (FM) and Performance Management (PM), may be optional confirming to 88 actual network management policies. Hence the network operator must 89 be able to choose which kind of OAM functions to apply to specific 90 connections and with what parameters the selected OAM functions 91 should be configured and operated. To achieve this objective OAM 92 entities and specific functions must be selectively configurable. 94 The GMPLS control plane consists of a set of protocols: OSPF-TE, 95 RSVP-TE and LMP. which are used to reduce manual configuration and 96 improve management efficiency. RSVP-TE is used to setup and 97 configure end-to-end connections. A new useful application of 98 RSVP-TE is OAM configuration and control for transport networks. 100 When RSVP-TE is used for LSP establishment it is desirable to bind 101 OAM setup to connection establishment signalling to avoid two 102 separate management/configuration steps (connection setup followed by 103 OAM configuration) which increases delay, processing and more 104 importantly may be prune to misconfiguration errors. 106 This document describes requirements on OAM configuration and control 107 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 108 providing a framework to configure and control OAM entities along 109 with capability to carry technology specific information. Extensions 110 can be grouped into generic elements that are applicable to any OAM 111 solution and technology specific elements that provide additional 112 configuration parameters only needed for a specific OAM technology. 113 This document specifies the technology agnostic elements that alone 114 can be used to establish OAM entities in the case no technology 115 specific information is needed, and specifies the way additional 116 technology specific OAM parameters are provided. 118 2. Requirements 120 MPLS OAM requirements are described in [RFC4377]. It provides 121 requirements to create consistent OAM functionality for MPLS 122 networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The 123 GMPLS OAM requirements are based on the MPLS OAM requirements 124 [RFC4377], in addition it also considers the existing OAM techniques 125 in non-packet networks. 127 The following list is an excerpt of MPLS OAM requirements documented 128 in [RFC4377]. Only a few requirements are discussed that bear a 129 direct relevance to the discussion set forth in this document. 131 o It is desired to support the automation of LSP defect detection. 132 It is especially important in cases where large numbers of LSPs 133 might be tested. 135 o In particular some LSPs may require automated ingress-LSR to 136 egress-LSR testing functionality, while others may not. 138 o Mechanisms are required to coordinate network responses to 139 defects. Such mechanisms may include alarm suppression, 140 translating defect signals at technology boundaries, and 141 synchronising defect detection times by setting appropriately 142 bounded detection timeframes. 144 MPLS-TP defines a profile of MPLS targeted at transport applications 145 [MPLS-TP-FWK]. This profile specifies the specific MPLS 146 characteristics and extensions required to meet transport 147 requirements, including providing additional OAM, survivability and 148 other maintenance functions not currently supported by MPLS. 149 Specific OAM requirements for MPLS-TP are specified in 150 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 151 to configure and control OAM entities. 153 o The use of OAM functions SHOULD be optional for the operator. A 154 network operator SHOULD be able to choose which OAM functions to 155 use and which Maintenance Entity to apply them to. 157 o The MPLS-TP control pane MUST support the configuration and 158 modification of OAM maintenance points as well as the activation/ 159 deactivation of OAM when the transport path is established or 160 modified. OAM functions SHOULD be configurable as part of 161 connectivity (LSP or PW) management. 163 Ethernet Connectivity Fault Management (CFM) defines an adjunct 164 connectivity monitoring OAM flow to check the liveliness of Ethernet 165 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 166 support explicitly-routed Ethernet connections. CFM can be used to 167 track the liveliness of PBB-TE connections and detect data plane 168 failures. In IETF the GMPLS controlled Ethernet Label Switching 169 (GELS) [GELS-Framework] work is extending the GMPLS control plane to 170 support the establishment of point-to-point PBB-TE data plane 171 connections. Without control plane support separate management 172 commands would be needed to configure and start CFM. 174 GMPLS based OAM configuration and control should be general to be 175 applicable to a wide range of data plane technologies and OAM 176 solution. There are three typical data plane technologies used for 177 transport application, which are wavelength based such as WSON, TDM 178 based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] 179 and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the 180 operator MUST be able to configure and control the following OAM 181 functions. 183 o It MUST be possible to explicitly request the setup of OAM 184 entities for the signalled LSP and provide specific information 185 for the setup if this is required by the technology. 187 o When periodic messages are used for liveliness check (continuity 188 check) of LSPs it MUST be possible to set the frequency of 189 messages allowing proper configuration for fulfilling the 190 requirements of the service and/or meeting the detection time 191 boundaries posed by possible congruent connectivity check 192 operations of higher layer applications. For a network operator 193 to be able to balance the trade-off in fast failure detection and 194 overhead it is beneficial to configure the frequency of continuity 195 check messages on a per LSP basis. 197 o Control of alarms is important to avoid false alarm indications 198 and reporting to the management system. It MUST be possible to 199 enable/disable alarms generated by OAM functions. In some cases 200 selective alarm control may be desirable when, for instance, the 201 operator is only concerned about critical alarms thus the non- 202 service affecting alarms should be inhibited. 204 o Performance Monitoring (PM) is continuously collecting information 205 about specific characteristics of the connection. It MUST be 206 possible to configure PM functions, e.g., set monitoring intervals 207 and thresholds for PM initiated alarms. For consistent 208 measurement of Service Level Agreements (SLAs) it may be required 209 that measurement points agree on a common probing rate to avoid 210 measurement problems. 212 o The extensions must allow the operator to use only a minimal set 213 of OAM configuration and control features if the data plane 214 technology, the OAM solution or network management policy allows. 215 The extensions must be reusable as much as reasonably possible. 216 That is generic OAM parameters and data plane or OAM technology 217 specific parameters must be separated. 219 3. GMPLS RSVP-TE Extensions 221 3.1. Operation overview 223 Two types of Maintenance Poits (MPs) are distinguished: Maintenance 224 End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs 225 are located at the ends of an LSP and are capable of initiating and 226 terminating OAM packets for Fault Management (FM) and Performance 227 Monitoring (PM). MIPs on the other hand are located at transit nodes 228 of an LSP and are capable of reacting to some OAM packets but 229 otherwise do not initiate packets. Maintenance Entity (ME) refers to 230 an association of MEPs and MIPs that are provisioned to monitor an 231 LSP. The ME association is achieved by configuring MPs of an ME with 232 the same unique ME ID. Each MEP must have unique identification (MEP 233 ID) within the ME. 235 When an LSP is signalled forwarding association is established 236 between endpoints and transit nodes via label bindings. This 237 association creates a context for the OAM entities monitoring the 238 LSP. On top of this association OAM entities may be configured with 239 an ME ID and MEP IDs. The ME ID may be used to detect 240 misconfiguration errors and leacking OAM traffic. Within the ME the 241 MEP ID can be used to demultiplex and identify the originating MEP of 242 OAM packets. Since MIPs do not originate OAM packets no specific 243 configuration is required for them. 245 In addition to the ME and MEP identification parameters pro-active 246 OAM functions (e.g., Continuity Check (CC), Performance Monitoring) 247 may have specific parameters requiring configuration as well. In 248 particular, the frequency of periodic CC packets and the measurement 249 interval for loss and delay measurements may need to be configured. 251 MEP 252 +-------------+ 253 |OAM Functions| 254 | FM | PM | 255 +------+------+ 256 | MEP ID | 257 +-------------+ 258 | ME ID | 259 +-------------+ 260 +-------------+ 261 | LSP | 262 +-------------+ 264 In some cases all the above parameters may be either derived form 265 some exiting information or pre-configured default values can be 266 used. In the simplest case the control plane needs to provide 267 information whether or not a ME with MPs need to be setup for the 268 signalled LSP. If OAM entities are created signalling must provide 269 means to activate/deactivate OAM message flows and associated alarms. 271 ME and MEP IDs as well as configuration of OAM functions are 272 technology specific, i.e., vary depending on the data plane 273 technology and the chosen OAM solution. In addition for any given 274 data plane technology a set of OAM solutions may be applicable. The 275 OAM configuration framework allows selecting a specific OAM solution 276 to be used for the signalled LSP and provides technology specific 277 TLVs to carry further detailed configuration information. 279 3.2. OAM entities desired -- LSP Attributes flag 281 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 282 indicate options and attributes of the LSP. The Flags field has 8 283 bits and hence is limited to differentiate only 8 options. [RFC4420] 284 defines a new object for RSVP-TE messages to allow the signalling of 285 arbitrary attribute parameters making RSVP-TE easily extensible to 286 support new applications. Furthermore, [RFC4420] allows options and 287 attributes that do not need to be acted on by all Label Switched 288 Routers (LSRs) along the path of the LSP. In particular, these 289 options and attributes may apply only to key LSRs on the path such as 290 the ingress LSR and egress LSR. Options and attributes can be 291 signalled transparently, and only examined at those points that need 292 to act on them. The LSP_ATTRIBUTES object and the 293 LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide 294 means to signal LSP attributes and options in the form of TLVs. 295 Options and attributes signalled in the LSP_ATTRIBUTES object can be 296 passed transparently through LSRs not supporting a particular option 297 or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES 298 object must be examined and processed by each LSR. One TLV is 299 defined in [RFC4420]: the Attributes Flags TLV. 301 A new bit (10 IANA to assign): "OAM entities desired" is allocated in 302 the LSP Attributes Flags TLV. If the "OAM entities desired" bit is 303 set it is indicating that the establishment of OAM entities are 304 required at the endpoints of the signalled LSP. If the establishment 305 of OAM entities is not supported an error must be generated: "OAM 306 Problem/OAM establishment not supported". 308 If the "OAM entities desired" bit is set and additional parameters 309 are needed to configure the OAM entities an OAM Configuration TLV may 310 be included in the LSP_ATTRIBUTES object. 312 3.3. OAM Configuration TLV 314 This TLV specifies which OAM technology/method should be used for the 315 LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES 316 object in Path messages. 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type (2) (IANA) | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | OAM Type | OAM Function | Reserved (set to all 0s) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 327 assign). 329 OAM Type: specifies the technology specify OAM method. If the 330 requested OAM method is not supported an error must be generated: 331 "OAM Problem/Unsupported OAM Type". 333 This document defines no types. The receiving node based on the OAM 334 Type will check if a corresponding technology specific OAM 335 configuration TLV is included. 337 OAM Function Flags: specifies proactive OAM functions (e.g., 338 connectivity monitoring, loss and delay measurement) that should be 339 established and configured. If the selected OAM Function(s) is(are) 340 not supported an error must be generated: "OAM Problem/Unsupported 341 OAM Function". 343 This document defines the following flags. 345 OAM Function Flag Description 346 --------------------- --------------------------- 347 0 Connectivity Monitoring 348 1-7 Reserved 350 3.4. Monitoring Disabled - Admin_Status bit 352 Administrative Status Information is carried in the ADMIN_STATUS 353 Object. The Administrative Status Information is described in 354 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 355 [RFC3473]. 357 One bit is allocated for the administrative control of OAM 358 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 359 occupied (assigned by IANA or temporarily blocked by work in progress 360 Internet drafts). As the 24th bit (IANA to assign) this draft 361 introduces the Monitoring Disabled (M) bit. When this bit is set the 362 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no 363 continuity check messages are sent). 365 3.5. OAM configuration errors 367 To handle OAM configuration errors a new Error Code (IANA to assign) 368 "OAM Problem" is introduced. To refer to specific problems a set of 369 Error Values is defined. 371 If a node does not support the establishment of OAM entities via 372 RSVP-TE signalling it must use the error value (IANA to assign): "OAM 373 establishment not supported" in the PathErr message. 375 If a node does not support a specific OAM technology/solution it must 376 use the error value (IANA to assign): "Unsupported OAM Type" in the 377 PathErr message. 379 If a node does not support a specific OAM Function it must use the 380 error value (IANA to assign): "Unsupported OAM Function" in the 381 PathErr message. 383 4. IANA Considerations 385 One bit (Monitoring Disabled (M)) needs to be allocated in the 386 ADMIN_STATUS Object. 388 One bit ("OAM entities desired") needs to be allocated in the LSP 389 Attributes Flag Registry. 391 This document specifies one new TLVs to be carried in the 392 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: 393 OAM Configuration TLV. 395 One new Error Code: "OAM Problem" and three new values: "OAM 396 establishment not supported", "Unsupported OAM Type" and "Unsupported 397 OAM Function" needs to be assigned. 399 5. Security Considerations 401 The signalling of OAM related parameters and the automatic 402 establishment of OAM entities introduces additional security 403 considerations to those discussed in [RFC3473]. In particular, a 404 network element could be overloaded, if an attacker would request 405 liveliness monitoring, with frequent periodic messages, for a high 406 number of LSPs, targeting a single network element. 408 Security aspects will be covered in more detailed in subsequent 409 versions of this document. 411 6. Acknowledgements 413 The authors would like to thank Francesco Fondelli, Adrian Farrel, 414 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 415 comments. 417 Appendix A. Discussion on alternatives 419 This appendix summarises the discussions after IETF-71 about the way 420 OAM configuration information should be carried in RSVP-TE. 422 The first question is how the requirement for OAM establishment is 423 signalled and how the operation of OAM is controlled. There is a 424 straightforward way to achieve these using existing objects and 425 fields: 427 o Use one or more OAM flags in the LSP Attributes Flag TLV within 428 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 429 OAM entities for the LSP need to be established. If for any 430 reason this cannot be done a notification is sent or an error is 431 raised. 433 o Once the LSP with the desired OAM entities is established OAM 434 operation may be controlled using one or more flags in the 435 ADMIN_STATUS object. For instance, the generation of connectivity 436 monitoring messages can be disabled/enabled by setting/clearing a 437 flag in the ADMIN_STATUS object. 439 However, there are two alternatives when it comes to signalling the 440 actual configuration parameters of OAM entities. 442 o Extension of the LSP_ATTRIBUTES object with new TLVs. 444 o Definition of a new RSVP-TE object to carry OAM information. 446 In the first case, a new OAM configuration TLV is defined in the 447 LSP_ATTRIBUTES object. This TLV would provide the detailed 448 information needed for LSPs with a set OAM flag in the LSP Attributes 449 Flag TLV. The rationale for this approach is that in addition to 450 setting flags the LSP_ATTRIBUTES object may carry complementary 451 information for all or some of the flags set. Furthermore, as top 452 level RSVP-TE objects may become scarce resources, it seems to be 453 beneficial not to allocate new RSVP-TE objects for the purpose of 454 providing detailed information for new LSP Attribute Flags. 455 Currently there is only one TLV, the Attributes Flag TLV, defined in 456 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 457 the flags would make a precedence and possibly be a guideline for 458 similar future extensions. 460 The other alternative would be to allocate a dedicated object for OAM 461 configuration information. The rationale for this is that the 462 complex information that may be required for OAM configuration would 463 unnecessarily add complexity to LSP_ATTRIBUTES/ 464 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 466 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 467 carry configuration information of data plane entities, thus a new 468 object like an "OAM_SPEC" may be a better fit to existing protocol 469 elements. 471 The authors of this document favour the first alternative (adding new 472 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 473 alternative to select for standardisation is up for the working group 474 to decide. In any case, the information to be carried would be the 475 same or very similar for both alternatives. 477 7. References 479 [GELS-Framework] 480 "GMPLS Ethernet Label Switching Architecture and 481 Framework", Internet Draft, work in progress. 483 [GMPLS-OAM] 484 "OAM Requirements for Generalized Multi-Protocol Label 485 Switching (GMPLS) Networks", Internet Draft, work in 486 progress. 488 [IEEE-CFM] 489 "IEEE 802.1ag, Draft Standard for Connectivity Fault 490 Management", work in progress. 492 [IEEE-PBBTE] 493 "IEEE 802.1Qay Draft Standard for Provider Backbone 494 Bridging Traffic Engineering", work in progress. 496 [MPLS-TP-FWK] 497 "A Framework for MPLS in Transport Networks", Internet 498 Draft, work in progress. 500 [MPLS-TP-OAM-REQ] 501 "Requirements for OAM in MPLS Transport Networks", 502 Internet Draft, work in progress. 504 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 505 Recovery", RFC 3469, February 2003. 507 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 508 Signaling Functional Description", RFC 3471, January 2003. 510 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 511 Signaling Resource ReserVation Protocol-Traffic 512 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 514 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 515 Protocol Label Switched (MPLS) Networks", RFC 4377, 516 February 2006. 518 [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching 519 (MPLS) Label Switched Path (LSP) Establishment Using 520 Resource ReserVation Protocol-Traffic Engineering 521 (RSVP-TE)", RFC 4420, February 2006. 523 Authors' Addresses 525 Attila Takacs 526 Ericsson 527 Laborc u. 1. 528 Budapest, 1037 529 Hungary 531 Email: attila.takacs@ericsson.com 533 Don Fedyk 534 Nortel 535 600 Technology Park Drive 536 Billerica, MA 01821 537 USA 539 Email: dwfedyk@nortel.com 541 He Jia 542 Huawei 544 Email: hejia@huawei.com 546 Full Copyright Statement 548 Copyright (C) The IETF Trust (2008). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org.