idnits 2.17.1 draft-ietf-ccamp-gmpls-recovery-functional-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1092. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1108), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Consider a node that detects a link failure. The node MUST determine the identities of all LSPs that are affected by the failure of the link, and send an end-to-end failure indication message to the source of each LSP. For scalability reasons, failure indication messages MAY contain the identity and the status of multiple LSPs rather than a single one. Each intermediate node receiving such a message MUST forward the message to the appropriate next node such that the message would ultimately reach the LSP source. However, there is no requirement that this message flows towards the source along the same path as the failed LSP. Furthermore, if an intermediate node is itself generating a failure indication message, there SHOULD be a mechanism to suppress all but one source of failure indication messages. Finally, the failure indication message MUST be sent reliably from the node detecting the failure to the LSP source. Reliability MAY be achieved, for example, by re-transmitting the message until an acknowledgement is received. However, retransmission of failure indication messages SHOULD not cause further message drops. This MAY be achieved through the appropriate configuration and use of congestion and flow control mechanisms. -- 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 (April 2005) is 6950 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-ARCH' is mentioned on line 145, but not defined == Unused Reference: 'RFC2026' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1060, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-16 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-09 ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- No information found for draft-ietf-gmpls-recovery-terminology - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jonathan P. Lang, Ed. 2 Internet Draft Bala Rajagopalan, Ed. 3 Category: Standards Track Dimitri Papadimitriou, Ed. 4 Expiration Date: October 2005 6 April 2005 8 Generalized Multi-Protocol Label Switching (GMPLS) Recovery 9 Functional Specification 11 draft-ietf-ccamp-gmpls-recovery-functional-04.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 42 Abstract 44 This document presents a functional description of the protocol 45 extensions needed to support Generalized Multi-Protocol Label 46 Switching (GMPLS)-based recovery (i.e. protection and restoration). 47 Protocol specific formats and mechanisms will be described in 48 companion documents. 50 Lang, J., Rajagopalan, B., et al - Standards Track 1 51 Table of Content 53 Status of this Memo .............................................. 1 54 Abstract ......................................................... 1 55 Table of Content ................................................. 2 56 Contributors ..................................................... 2 57 1. Conventions ................................................... 3 58 2. Introduction .................................................. 3 59 3. Span Protection ............................................... 4 60 3.1 Unidirectional 1+1 dedicated protection ...................... 5 61 3.2 Bi-directional 1+1 dedicated protection ...................... 6 62 3.3 Dedicated 1:1 protection with Extra Traffic .................. 6 63 3.4 Shared M:N protection ........................................ 8 64 3.5 Messages .................................................... 10 65 3.5.1 Failure Indication Message ................................ 11 66 3.5.2 Switchover Request Message ................................ 11 67 3.5.3 Switchover Response Message ............................... 12 68 3.6 Preventing Unintended Connections ........................... 12 69 4. End-to-End (Path) Protection and Restoration ................. 12 70 4.1 Unidirectional 1+1 Protection ............................... 12 71 4.2 Bi-directional 1+1 Protection ............................... 12 72 4.2.1 Identifiers ............................................... 13 73 4.2.2 Nodal Information ......................................... 13 74 4.2.3 End-to-End Failure Indication Message ..................... 14 75 4.2.4 End-to-End Failure Acknowledgment Message ................. 14 76 4.2.5 End-to-End Switchover Request Message ..................... 15 77 4.2.6 End-to-End Switchover Response Message .................... 15 78 4.3 Shared Mesh Restoration ..................................... 15 79 4.3.1 End-to-End Failure Indication and Acknowledgment .......... 16 80 4.3.2 End-to-End Switchover Request Message ..................... 16 81 4.3.3 End-to-End Switchover Response Message .................... 16 82 5. Reversion and other Administrative Procedures ................ 16 83 6. Discussion ................................................... 17 84 6.1 LSP Priorities During Protection ............................ 17 85 7. Security Considerations ...................................... 18 86 8. IANA Considerations .......................................... 19 87 9. Editor's Addresses ........................................... 19 88 10. References .................................................. 19 89 10.1 Normative References ....................................... 19 90 10.2 Informative References ..................................... 20 91 Intellectual Property Statement ................................. 21 92 Disclaimer of Validity .......................................... 21 93 Copyright Statement ............................................. 21 95 Contributors 97 This document was the product of many individuals working together 98 in the CCAMP WG Protection and Restoration design team. The 99 following are the authors that contributed to this document: 101 Deborah Brungard (AT&T) 102 200 S. Laurel Ave. 103 Middletown, NJ 07748, USA 104 EMail: dbrungard@att.com 106 Lang, J., Rajagopalan, B., et al - Standards Track 2 107 Sudheer Dharanikota 108 EMail: sudheer@ieee.org 110 Jonathan P. Lang (Sonos) 111 506 Chapala Street 112 Santa Barbara, CA 93101, USA 113 EMail: jplang@ieee.org 115 Guangzhi Li (AT&T) 116 180 Park Avenue, 117 Florham Park, NJ 07932, USA 118 E-mail: gli@research.att.com 120 Eric Mannie 121 EMail: eric_mannie@hotmail.com 123 Dimitri Papadimitriou (Alcatel) 124 Francis Wellesplein, 1 125 B-2018 Antwerpen, Belgium 126 EMail: dimitri.papadimitriou@alcatel.be 128 Bala Rajagopalan (Intel Broadband Wireless Division) 129 2111 NE 25th Ave. 130 Hillsboro, OR 97124, USA 131 EMail: bala.rajagopalan@intel.com 133 Yakov Rekhter (Juniper) 134 1194 N. Mathilda Avenue 135 Sunnyvale, CA 94089, USA 136 EMail: yakov@juniper.net 138 1. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 In addition, the reader is assumed to be familiar with the 145 terminology used in [GMPLS-ARCH], [RFC3471] and referenced as well 146 as [TERM]. 148 2. Introduction 150 A requirement for the development of a common control plane for both 151 optical and electronic switching equipment is that there must be 152 signaling, routing, and link management mechanisms that support data 153 plane fault recovery. In this document, the term "recovery" is 154 generically used to denote both protection and restoration; the 155 specific terms "protection" and "restoration" are only used when 156 differentiation is required. The subtle distinction between 157 protection and restoration is made based on the resource allocation 158 done during the recovery period (see [TERM]). 160 Lang, J., Rajagopalan, B., et al - Standards Track 3 161 A label-switched path (LSP) may be subject to local (span), segment, 162 and/or end-to-end recovery. Local span protection refers to the 163 protection of the link (and hence all the LSPs marked as required 164 for span protection and routed over the link) between two 165 neighboring switches. Segment protection refers to the recovery of 166 an LSP segment (i.e., an SNC in the ITU-T terminology) between two 167 nodes, i.e. the boundary nodes of the segment. End-to-end protection 168 refers to the protection of an entire LSP from the ingress to the 169 egress port. The end-to-end recovery models discussed in this 170 document apply to segment protection where the source and 171 destination refer to the protected segment rather than the entire 172 LSP. Multiple recovery levels may be used concurrently by a single 173 LSP for added resiliency; however, the interaction between levels 174 becomes affecting any one direction of the LSP results in both 175 directions of the LSP being switched to a new span, segment, or end- 176 to-end path. 178 Unless otherwise stated, all references to "link" in this document 179 indicate a bi-directional link (which may be realized as a pair of 180 unidirectional links). 182 Consider the control plane message flow during the establishment of 183 an LSP. This message flow proceeds from an initiating (or source) 184 node to a terminating (or destination) node, via a sequence of 185 intermediate nodes. A node along the LSP is said to be "upstream" 186 from another node if the former occurs first in the sequence. The 187 latter node is said to be "downstream" from the former node. That 188 is, an "upstream" node is closer to the initiating node than a node 189 further "downstream". Unless otherwise stated, all references to 190 "upstream" and "downstream" are in terms of the control plane 191 message flow. 193 The flow of the data traffic is defined from ingress (source node) 194 to egress (destination node). Note that for bi-directional LSPs 195 there are two different data plane flows, one for each direction of 196 the LSP. This document presents a protocol functional description to 197 support Generalized Multi-Protocol Label Switching (GMPLS)-based 198 recovery (i.e., protection and restoration). Protocol specific 199 formats, encoding and mechanisms will be described in companion 200 documents. 202 3. Span Protection 204 Consider a (working) link i between two nodes A and B. There are two 205 fundamental models for span protection. The first is referred to as 206 1+1 protection. Under this model, a dedicated link j is pre-assigned 207 to protect link i. LSP traffic is permanently bridged onto both 208 links i and j at the ingress node and the egress node selects the 209 signal (i.e., normal traffic) from i or j, based on a selection 210 function (e.g., signal quality). Under unidirectional 1+1 span 211 protection (Section 3.1), each node A and B acts autonomously to 212 select the signal from the working link (i) or the protection link 213 (j). Under bi-directional 1+1 span protection (Section 3.2) the two 215 Lang, J., Rajagopalan, B., et al - Standards Track 4 216 nodes A and B coordinate the selection function such that they 217 select the signal from the same link, i or j. 219 Under the second model, a set of N working links are protected by a 220 set of M protection links, usually with M =< N. A failure in any of 221 the N working links results in traffic being switched to one of the 222 M protection links that is available. This is typically a three-step 223 process: first the data plane failure is detected at the egress node 224 and reported (notification), then a protection link is selected, and 225 finally, the LSPs on the failed link are moved to the protection 226 link. If reversion is supported, a fourth step is included, i.e. 227 return of the traffic to the working link (when the working link has 228 recovered from the failure). In Section 3.3, 1:1 span protection is 229 described. In Section 3.4, M:N span protection is described, where M 230 =< N. 232 3.1 Unidirectional 1+1 dedicated protection 234 Suppose a bi-directional LSP is routed over link i between two nodes 235 A and B. Under unidirectional 1+1 protection, a dedicated link j is 236 pre-assigned to protect the working link i. LSP traffic is 237 permanently bridged on both links at the ingress node and the egress 238 node selects the normal traffic from one of the links, i or j. If a 239 node (A or B) detects a failure of a span, it autonomously invokes a 240 process to receive the traffic from the protection span. Thus, it is 241 possible that node A selects the signal from link i in the B to A 242 direction of the LSP, and node B selects the signal from link j in 243 the A to B direction. 245 The following functionality is required for 1+1 unidirectional span 246 protection: 248 o Routing: A single TE link encompassing both working and 249 protection links SHOULD be announced with Link Protection 250 Type "Dedicated 1+1" along with the bandwidth parameters for 251 the working link. As the resources are consumed/released, 252 the bandwidth parameters of the TE link are adjusted 253 accordingly. Encoding of the Link Protection Type and 254 bandwidth parameters in IS-IS is specified in [GMPLS-ISIS]. 255 Encoding of this information in OSPF is specified in [GMPLS- 256 OSPF]. 258 o Signaling: The Link Protection object/TLV SHOULD be used to 259 request "Dedicated 1+1" link protection for that LSP. This 260 object/TLV is defined in [RFC3471]. If the Link Protection 261 object/TLV is not used, link selection is a matter of local 262 policy. No additional signaling is required when a fail-over 263 occurs. 265 o Link management: Both nodes MUST have a consistent view of 266 the link protection association for the spans. This can be 267 done using the Link Management Protocol (LMP) [LMP], or if 268 LMP is not used, this MUST be configured manually. 270 Lang, J., Rajagopalan, B., et al - Standards Track 5 271 3.2 Bi-directional 1+1 dedicated protection 273 Suppose a bi-directional LSP is routed over link i between two nodes 274 A and B. Under bi-directional 1+1 protection, a dedicated link j is 275 pre-assigned to protect the working link i. LSP traffic is 276 permanently duplicated on both links and under normal conditions, 277 the traffic from link i is received by nodes A and B (in the 278 appropriate directions). A failure affecting link i results in both 279 A and B switching to the traffic on link j in the respective 280 directions. Note that some form of signaling is required to ensure 281 that both A and B start receiving from the protection link. 283 The basic steps in 1+1 bi-directional span protection are as 284 follows: 286 1. If a node (A or B) detects the failure of the working link 287 (or a degradation of signal quality over the working link), 288 it SHOULD begin receiving on the protection link and send a 289 switchover request message reliably to the other node (B or 290 A, respectively). This message SHOULD indicate the identity 291 of the failed working link and other relevant information. 293 2. Upon receipt of the switchover request message, a node MUST 294 begin receiving from the protection link and send a 295 switchover response message to the other node (A or B, 296 respectively). Since both the working/protect spans are 297 exposed to routing and signaling as a single link, the 298 switchover SHOULD be transparent to routing and signaling. 300 The following functionality is required for 1+1 bi-directional span 301 protection: 303 o The routing procedures are the same as in 1+1 304 unidirectional. 306 o The signaling procedures are the same as in 1+1 307 unidirectional. 309 o In addition to the procedures described in 1+1 310 (unidirectional), a switchover request message MUST be used 311 to signal the switchover request. This can be done using LMP 312 [LMP]. Note that GMPLS-based mechanisms MAY not be necessary 313 when the underlying span (transport) technology provides 314 such a mechanism. 316 3.3 Dedicated 1:1 protection with Extra Traffic 318 Consider two adjacent nodes A and B. Under 1:1 protection, a 319 dedicated link j between A and B is pre-assigned to protect working 320 link i. Link j may be carrying (preemptable) Extra Traffic. A 321 failure affecting link i results in the corresponding LSP(s) being 322 restored to link j. Extra Traffic being routed over link j may need 323 to be preempted to accommodate the LSPs that have to be restored. 325 Lang, J., Rajagopalan, B., et al - Standards Track 6 326 Once a fault is isolated/localized, the affected LSP(s) must be 327 moved to the protection link. The process of moving an LSP from a 328 failed (working) link to a protection link must be initiated by one 329 of the nodes, A or B. This node is referred to as the "master". The 330 other node is called the "slave". The determination of the master 331 and the slave may be based on configured information or protocol 332 specific requirements. 334 The basic steps in dedicated 1:1 span protection (ignoring 335 reversion) are as follows: 337 1. If the master detects/localizes a link failure event, it 338 invokes a process to allocate the protection link to the 339 affected LSP(s). 340 2. If the slave detects a link failure event, it informs the 341 master of the failure using a failure indication message. 342 The master then invokes the same procedure as (1) to move 343 the LSPs to the protection link. If the protection link is 344 carrying Extra Traffic, the slave stops using the span for 345 the Extra Traffic. 346 3. Once the span protection procedure is invoked in the master, 347 it requests the slave to switch the affected LSP(s) to the 348 protection link. Prior to this, if the protection link is 349 carrying Extra Traffic, the master stops using the span for 350 this traffic (i.e., the traffic is dropped by the master and 351 not forwarded into or out of the protection link). 352 4. The slave sends an acknowledgement to the master. Prior to 353 this, the slave stops using the link for Extra Traffic (i.e. 354 the traffic is dropped by the slave and not forwarded into 355 or out of the protection link). It then starts sending the 356 normal traffic on the selected protection link. 357 5. When the master receives the acknowledgement, it starts 358 sending and receiving the normal traffic over the new link. 359 The switchover of the LSPs is thus completed. 361 Note: though this mechanism implies more traffic dropped than 362 necessary, it is preferred over possible misconnections during 363 the recovery process. 365 From the description above, it is clear that 1:1 span protection may 366 require up to three signaling messages for each failed span: a 367 failure indication message, an LSP switchover request message, and 368 an LSP switchover response message. Furthermore, it may be possible 369 to switch multiple LSPs from the working span to the protection span 370 simultaneously. 372 The following functionality is required for dedicated 1:1 span 373 protection: 375 o Pre-emption MUST be supported to accommodate Extra Traffic. 377 o Routing: A single TE link encompassing both working and 378 protection links is announced with Link Protection Type 379 "Dedicated 1:1". If Extra Traffic is supported over the 381 Lang, J., Rajagopalan, B., et al - Standards Track 7 382 protection link, then the bandwidth parameters for the 383 protection link MUST also be announced. The differentiation 384 between bandwidth for working and protect links is made 385 using priority mechanisms. In other words, the network MUST 386 be configured such that bandwidth at priority X or lower is 387 considered Extra Traffic. 389 If there is a failure on the working link, then the normal 390 traffic is switched to the protection link, preempting Extra 391 Traffic if necessary. The bandwidth for the protection link 392 MUST be adjusted accordingly. 394 o Signaling: To establish an LSP on the working link, the Link 395 Protection object/TLV indicating "Dedicated 1:1" SHOULD be 396 included in the signaling request message for that LSP. To 397 establish an LSP on the protection link, the appropriate 398 priority (indicating Extra Traffic) SHOULD be used for that 399 LSP. These objects/TLVs are defined in [RFC3471]. If the 400 Link Protection object/TLV is not used, link selection is a 401 matter of local policy. 403 o Link management: Both nodes MUST have a consistent view of 404 the link protection association for the spans. This can be 405 done using LMP [LMP] or via manual configuration. 407 o When a link failure is detected at the slave, a failure 408 indication message MUST be sent to the master informing the 409 node of the link failure. 411 3.4 Shared M:N protection 413 Shared M:N protection is described with respect to two neighboring 414 nodes A and B. The scenario considered is as follows: 416 o At any point in time, there are two sets of links between A 417 and B, i.e., a working set of N (bi-directional) links 418 carrying traffic subject to protection and a protection set 419 of M (bi-directional) links. A protection link may be 420 carrying Extra Traffic. There is no a priori relationship 421 between the two sets of links, but the value of M and N MAY 422 be pre-configured. The specific links in the protection set 423 MAY be pre-configured to be physically diverse to avoid the 424 possibility that failure events affect a large proportion of 425 protection links (along with working links). 427 o When a link in the working set is affected by a failure, the 428 normal traffic is diverted to a link in the protection set, 429 if such a link is available. Note that such a link might be 430 carrying more than one LSP, e.g., an OC-192 link carrying 431 four STS-48 LSPs. 433 o More than one link in the working set may be affected by the 434 same failure event. In this case, there may not be an 435 adequate number of protection links to accommodate all of 437 Lang, J., Rajagopalan, B., et al - Standards Track 8 438 the affected traffic carried by failed working links. The 439 set of affected working links that are actually restored 440 over available protection links is then subject to policies 441 (e.g., based on relative priority of working traffic). These 442 policies are not specified in this document. 444 o When normal traffic must be diverted from a failed link in 445 the working set to a protection link, the decision as to 446 which protection link is chosen is always made by one of the 447 nodes, A or B. This node is considered the "master" and it 448 is required to both apply any policies and select specific 449 protection links to divert working traffic. The other node 450 is considered the "slave". The determination of the master 451 and the slave MAY be based on configured information, 452 protocol specific requirements, or as a result of running a 453 neighbor discovery procedure. 455 o Failure events themselves are detected by transport layer 456 mechanisms if available (e.g., SONET Alarm Indication Signal 457 (AIS)/ Remote Defect Indication (RDI)). Since the bi- 458 directional links are formed by a pair of unidirectional 459 links, a failure in the link from A to B is typically 460 detected by B and a failure in the opposite direction is 461 detected by A. It is possible that a failure simultaneously 462 affects both directions of the bi-directional link. In this 463 case, A and B will concurrently detect failures, in the B- 464 to-A direction and in the A-to-B direction, respectively. 466 The basic steps in M:N protection (ignoring reversion) are as 467 follows: 469 1. If the master detects a failure of a working link, it 470 autonomously invokes a process to allocate a protection link 471 to the affected traffic. 473 2. If the slave detects a failure of a working link, it MUST 474 inform the master of the failure using a failure indication 475 message. The master then invokes the same procedure as above 476 to allocate a protection link. (It is possible that the 477 master has itself detected the same failure, for example, a 478 failure simultaneously affecting both directions of a link). 480 3. Once the master has determined the identity of the 481 protection link, it indicates this to the slave and requests 482 the switchover of the traffic (using a "switchover request" 483 message). Prior to this, if the protection link is carrying 484 Extra Traffic, the master stops using the link for this 485 traffic (i.e., the traffic is dropped by the master and not 486 forwarded into or out of the protection link). 488 4. The slave sends a "switchover response" message back to the 489 master. Prior to this, if the selected protection link is 490 carrying traffic that could be preempted, the slave stops 491 using the link for this traffic (i.e., the traffic is 493 Lang, J., Rajagopalan, B., et al - Standards Track 9 494 dropped by the slave and not forwarded into or out of the 495 protection link). It then starts sending the normal traffic 496 on the selected protection link. 498 5. When the master receives the switchover response, it starts 499 sending and receiving the traffic that was previously 500 carried on the now-failed link over the new link. 502 Note: though this mechanism implies more traffic dropped than 503 necessary, it is preferred over possible misconnections during 504 the recovery process. 506 From the description above, it is clear that M:N span restoration 507 (involving LSP local recovery) MAY require up to three messages for 508 each working link being switched: a failure indication message, a 509 switchover request message and a switchover response message. 511 The following functionality is required for M:N span restoration: 513 o Pre-emption MUST be supported to accommodate Extra Traffic. 515 o Routing: A single TE link encompassing both sets of working 516 and protect links should be announced with Link Protection 517 Type "Shared M:N". If Extra Traffic is supported over set of 518 the protection links, then the bandwidth parameters for the 519 set of protection links MUST also be announced. The 520 differentiation between bandwidth for working and protect 521 links is made using priority mechanisms. 523 If there is a failure on a working link, then the affected 524 LSP(s) MUST be switched to a protection link, preempting 525 Extra Traffic if necessary. The bandwidth for the protection 526 link MUST be adjusted accordingly. 528 o Signaling: To establish an LSP on the working link, the Link 529 Protection object/TLV indicating "Shared M:N" SHOULD be 530 included in the signaling request message for that LSP. To 531 establish an LSP on the protection link, the appropriate 532 priority (indicating Extra Traffic) SHOULD be used for that. 533 These objects/TLVs are defined in [RFC3471]. If the Link 534 Protection object/TLV is not used, link selection is a 535 matter of local policy. 537 o For link management, both nodes MUST have a consistent view 538 of the link protection association for the links. This can 539 be done using LMP [LMP] or via manual configuration. 541 3.5 Messages 543 The following messages are used in local span protection procedures. 545 These messages SHOULD be delivered reliably. Therefore, the protocol 546 mechanisms used to deliver these messages SHOULD provide sequencing, 548 Lang, J., Rajagopalan, B., et al - Standards Track 10 549 acknowledgment and retransmission. The protocol SHOULD also handle 550 situations where the message(s) can not be delivered. 552 The messages described in the following subsections are abstract, 553 their format and encoding will be described in separate documents. 555 3.5.1 Failure Indication Message 557 This message is sent from the slave to the master to indicate the 558 identities of one or more failed working links. This message MAY not 559 be necessary when the transport plane technology itself provides for 560 such a notification. 562 The number of links included in the message would depend on the 563 number of failures detected within a window of time by the sending 564 node. A node MAY choose to send separate failure indication messages 565 in the interest of completing the recovery for a given link within 566 an implementation-dependent time constraint. 568 3.5.2 Switchover Request Message 570 Under bi-directional 1+1 span protection, this message is used to 571 coordinate the selecting function at both nodes. This message is 572 originated at the node that detected the failure. 574 Under dedicated 1:1 and shared M:N span protection, this message is 575 used as an LSP switchover request. This message is sent from the 576 master node to the slave node (reliably) to indicate that the LSP(s) 577 on the (failed) working link can be switched to an available 578 protection link. If so, the ID of the protection link as well as the 579 LSP labels (if necessary) MUST be indicated. These identifiers used 580 MUST be consistent with those used in GMPLS signaling. 582 A working link may carry multiple LSPs. Since the normal traffic 583 carried over the working link is switched to the protection link, it 584 MAY be possible for the LSPs on the working link to be mapped to the 585 protection link without re-signaling each individual LSP. For 586 example, if link bundling [BUNDLE] is used where the working and 587 protect links are mapped to component links, and the labels are the 588 same on the working and protection links, it MAY be possible to 589 change the component links without needing to re-signal each 590 individual LSP. Optionally, the labels MAY need to be explicitly 591 coordinated between the two nodes. In this case, the switchover 592 request message SHOULD carry the new label mappings. 594 The master may not be able to find protection links to accommodate 595 all failed working links. Thus, if this message is generated in 596 response to a Failure Indication message from the slave then the set 597 of failed links in the message MAY be a sub-set of the links 598 received in the Failure Indication message. Depending on time 599 constraints, the master may switch the normal traffic from the set 600 of failed links in smaller batches. Thus, a single failure 601 indication message MAY result in the master sending more than one 602 Switchover Request message to the same slave node. 604 Lang, J., Rajagopalan, B., et al - Standards Track 11 605 3.5.3 Switchover Response Message 607 This message is sent from the slave to the master (reliably) to 608 indicate the completion (or failure) of switchover at the slave. In 609 this message, the slave MAY indicate that it cannot switch over to 610 the corresponding free link for some reason. The master and slave in 611 this case notify the user (operator) of the failed switchover. A 612 notification of the failure MAY also be used as a trigger in an end- 613 to-end recovery. 615 3.6 Preventing Unintended Connections 617 An unintended connection occurs when traffic from the wrong source 618 is delivered to a receiver. This MUST be prevented during protection 619 switching. This is primarily a concern when the protection link is 620 being used to carry Extra Traffic. In this case, it MUST be ensured 621 that the LSP traffic being switched from the (failed) working link 622 to the protection link is not delivered to the receiver of the 623 preempted traffic. Thus, in the message flow described above, the 624 master node MUST disconnect (any) preempted traffic on the selected 625 protection link before sending the Switchover Request. The slave 626 node MUST also disconnect preempted traffic before sending the 627 Switchover Response. In addition, the master node SHOULD start 628 receiving traffic for the protected LSP from the protection link. 629 Finally, the master node SHOULD start sending protected traffic on 630 the protection link upon receipt of the Switchover Response. 632 4. End-to-End (Path) Protection and Restoration 634 End-to-end path protection and restoration refer to the recovery of 635 an entire LSP from the initiator to the terminator. Suppose the 636 primary path of an LSP is routed from the initiator (Node A) to the 637 terminator (Node B) through a set of intermediate nodes. 639 The following subsections describe three previously proposed end-to- 640 end protection schemes and the functional steps needed to implement 641 them. 643 4.1 Unidirectional 1+1 Protection 645 A dedicated, resource-disjoint alternate path is pre-established to 646 protect the LSP. Traffic is simultaneously sent on both paths and 647 received from one of the functional paths by the end nodes A and B. 649 There is no explicit signaling involved with this mode of 650 protection. 652 4.2 Bi-directional 1+1 Protection 654 A dedicated, resource-disjoint alternate path is pre-established to 655 protect the LSP. Traffic is simultaneously sent on both paths; under 656 normal conditions, the traffic from the working path is received by 657 nodes A and B (in the appropriate directions). A failure affecting 659 Lang, J., Rajagopalan, B., et al - Standards Track 12 660 the working path results in both A and B switching to the traffic on 661 the protection path in the respective directions. 663 Note that this requires coordination between the end nodes to switch 664 to the protection path. 666 The basic steps in bi-directional 1+1 path protection are as 667 follows: 669 o Failure detection: There are two possibilities for this. 671 1. A node in the working path detects a failure event. 672 Such a node MUST send a failure indication message 673 towards the upstream or/and downstream end node of the 674 LSP (node A or B). This message MAY be forwarded along 675 the working path, or routed over a different path if 676 the network has general routing intelligence. 678 Mechanisms provided by the data transport plane MAY 679 also be used for this, if available. 681 2. The end nodes (A or B) detect the failure themselves 682 (e.g., loss of signal). 684 o Switchover: The action when an end node detects a failure in 685 the working path is as follows: Start receiving from the 686 protection path; at the same time, send a switchover request 687 message to the other end node to enable switching at the 688 other end. 690 The action when an end node receives a switchover request 691 message is as follows: 693 - Start receiving from the protection path; at the same 694 time, send a switchover response message to the other 695 end node. 697 GMPLS signaling mechanisms MAY be used to (reliably) signal the 698 failure indication message, as well as the switchover request and 699 response message. These messages MAY be forwarded along the 700 protection path if no other routing intelligence is available in the 701 network. 703 4.2.1 Identifiers 705 LSP Identifier: A unique identifier for each LSP. The LSP Identifier 706 is within the scope of the Source ID and Destination ID. 708 Source ID: ID of the source (e.g., IP address). 710 Destination ID: ID of the destination (e.g., IP address). 712 4.2.2 Nodal Information 714 Lang, J., Rajagopalan, B., et al - Standards Track 13 715 Each node that is on the working or protection path of an LSP MUST 716 have knowledge of the LSP identifier. If the network does not 717 provide routing intelligence, nodal information MAY also include 718 previous and next nodes in the LSP so that restoration-related 719 messages can be forwarded properly. When, the network provides 720 general routing intelligence, messages MAY be forwarded along paths 721 different than that of the LSP. 723 At the end-point nodes, the working and protection paths MUST be 724 associated. The association of these paths MAY be either provisioned 725 using signaling, or MAY be configured when LSP provisioning does not 726 involve signaling (e.g., provisioning through a management system). 727 The related association information MUST remain until the LSP is 728 explicitly de-provisioned. 730 4.2.3 End-to-End Failure Indication Message 732 This message is sent (reliably) by an intermediate node towards the 733 source of an LSP. For instance, such a node might have attempted 734 local span protection and failed. This message MAY not be necessary 735 if the data transport layer provides mechanisms for the notification 736 of LSP failure by the endpoints (i.e. if LSP endpoints are co- 737 located with a corresponding data (transport) maintenance/recovery 738 domain). 740 Consider a node that detects a link failure. The node MUST determine 741 the identities of all LSPs that are affected by the failure of the 742 link, and send an end-to-end failure indication message to the 743 source of each LSP. For scalability reasons, failure indication 744 messages MAY contain the identity and the status of multiple LSPs 745 rather than a single one. Each intermediate node receiving such a 746 message MUST forward the message to the appropriate next node such 747 that the message would ultimately reach the LSP source. However, 748 there is no requirement that this message flows towards the source 749 along the same path as the failed LSP. Furthermore, if an 750 intermediate node is itself generating a failure indication message, 751 there SHOULD be a mechanism to suppress all but one source of 752 failure indication messages. Finally, the failure indication message 753 MUST be sent reliably from the node detecting the failure to the LSP 754 source. Reliability MAY be achieved, for example, by re-transmitting 755 the message until an acknowledgement is received. However, 756 retransmission of failure indication messages SHOULD not cause 757 further message drops. This MAY be achieved through the appropriate 758 configuration and use of congestion and flow control mechanisms. 760 4.2.4 End-to-End Failure Acknowledgment Message 762 This message is sent by the source node to acknowledge the receipt 763 of an End-to-End failure indication message. This message is sent to 764 the originator of the failure indication message. The acknowledge 765 message SHOULD be sent for each failure indication message received. 766 Each intermediate node receiving the failure acknowledgment message 767 MUST forward it towards the destination of the message. However, 769 Lang, J., Rajagopalan, B., et al - Standards Track 14 770 there is no requirement that this message flows towards the 771 destination along the same path as the failed LSP. 773 This message MAY not be required if other means of ensuring reliable 774 message delivery are used. 776 4.2.5 End-to-End Switchover Request Message 778 This message is generated by the source node receiving an indication 779 of failure in an LSP. It is sent to the LSP destination, and it 780 carries the identifier of LSP being restored. The End-to-End 781 Switchover Request message MUST be sent reliably from the source to 782 the destination of the LSP. 784 4.2.6 End-to-End Switchover Response Message 786 This message is sent by the destination node receiving an End-to-End 787 Switchover Request message towards the source of the LSP. This 788 message SHOULD identify the LSP being switched over. This message 789 MUST be transmitted in response to each End-to-End Switchover 790 Request message received and MAY indicate either a positive or 791 negative outcome. 793 4.3 Shared Mesh Restoration 795 Shared mesh restoration refers to schemes under which protection 796 paths for multiple LSPs share common link and node resources. Under 797 these schemes, the protection capacity is pre-reserved, i.e., link 798 capacity is allocated to protect one or more LSPs but explicit 799 action is required to instantiate a specific protection LSP. This 800 requires restoration signaling along the protection path. Typically, 801 the protection capacity is shared only amongst LSPs whose working 802 paths are physically diverse. This criterion can be enforced when 803 provisioning the protection path. Specifically, provisioning-related 804 signaling messages may carry information about the working path to 805 nodes along the protection path. This can be used as call admission 806 control to accept/reject connections along the protection path based 807 on the identification of the resources used for the primary path. 809 Thus, shared mesh restoration is designed to protect an LSP after a 810 single failure event, i.e., a failure that affects the working path 811 of at most one LSP sharing the protection capacity. It is possible 812 that a protection path may not be successfully activated when 813 multiple, concurrent failure events occur. In this case, shared mesh 814 restoration capacity may be claimed for more than one failed LSP and 815 the protection path can be activated only for one of them (at most). 817 For implementing shared mesh restoration, the identifier and nodal 818 information related to signaling along the control path are as 819 defined for 1+1 protection in Sections 4.2.1 and 4.2.2. In addition, 820 each node MUST also keep (local) information needed to establish the 821 data plane of the protection path. This information MUST indicate 822 the local resources to be allocated, the fabric cross-connect to be 823 established to activate the path, etc. The precise nature of this 825 Lang, J., Rajagopalan, B., et al - Standards Track 15 826 information would depend on the type of node and LSP (the GMPLS 827 signaling document describes different type of switches [RFC3471]). 828 It would also depend on whether the information is fine or coarse- 829 grained. For example, fine-grained information would indicate pre- 830 selection of all details pertaining to protection path activation, 831 such as outgoing link, labels, etc. Coarse-grained information, on 832 the other hand, would allow some details to be determined during 833 protection path activation. For example, protection resources may be 834 pre-selected at the level of a TE link, while the selection of the 835 specific component link and label occurs during protection path 836 activation. 838 While the coarser specification allows some flexibility in selection 839 of the precise resource to activate, it also brings in more 840 complexity in decision making and signaling during the time-critical 841 restoration phase. Furthermore, the procedures for the assignment of 842 bandwidth to protection paths MUST take into account the total 843 resources in a TE link so that single-failure survivability 844 requirements are satisfied. 846 4.3.1 End-to-End Failure Indication and Acknowledgment Message 848 The End-to-End failure indication and acknowledgement procedures and 849 messages are as defined in Sections 4.2.3 and 4.2.4. 851 4.3.2 End-to-End Switchover Request Message 853 This message is generated by the source node receiving an indication 854 of failure in an LSP. It is sent to the LSP destination along the 855 protection path, and it identifies the LSP being restored. If any 856 intermediate node is unable to establish cross-connects for the 857 protection path, then it is desirable that no other node in the path 858 establishes cross-connects for the path. This would allow shared 859 mesh restoration paths to be efficiently utilized. 861 The End-to-End Switchover message MUST be sent reliably from the 862 source to the destination of the LSP along the protection path. 864 4.3.3 End-to-End Switchover Response Message 866 This message is sent by the destination node receiving an End-to-End 867 Switchover Request message towards the source of the LSP, along the 868 protection path. This message SHOULD identify the LSP that is being 869 switched over. Prior to activating the secondary bandwidth at each 870 hop along the path, Extra Traffic (if used) MUST be dropped and not 871 forwarded 873 This message MUST be transmitted in response to each End-to-End 874 Switchover Request message received. 876 5. Reversion and other Administrative Procedures 878 Reversion refers to the process of moving an LSP back to the 879 original working path after a failure is cleared and the path is 881 Lang, J., Rajagopalan, B., et al - Standards Track 16 882 repaired. Reversion applies both to local span and end-to-end path 883 protected LSPs. Reversion is desired for the following reasons. 884 First, the protection path may not be optimal as compared to the 885 working path from a routing and resource consumption point of view. 886 Second, moving an LSP to its working path allows the protection 887 resources to be used to protect other LSPs. Reversion has the 888 disadvantage of causing a second service disruption. Use of 889 reversion is at the option of the operator. Reversion implies that a 890 working path remains allocated to the LSP that was originally routed 891 over it even after a failure. It is important to have mechanisms 892 that allow reversion to be performed with minimal service disruption 893 to the customer. This can be achieved using a "bridge-and-switch" 894 approach (often referred to as make-before-break). 896 The basic steps involved in bridge-and-switch are: 898 1. The source node commences the process by "bridging" the 899 normal traffic onto both the working and the protection 900 paths (or links in the case of span protection). 901 2. Once the bridging process is complete, the source node sends 902 a Bridge and Switch Request message to the destination, 903 identifying the LSP and other information necessary to 904 perform reversion. Upon receipt of this message, the 905 destination selects the traffic from the working path. At 906 the same time, it bridges the transmitted traffic onto both 907 the working and protection paths. 908 3. The destination then sends a Bridge and Switch Response 909 message to the source confirming the completion of the 910 operation. 911 4. When the source receives this message, it switches to 912 receive from the working path, and stops transmitting 913 traffic on the protection path. The source then sends a 914 Bridge and Switch Completed message to the destination 915 confirming that the LSP has been reverted. 916 5. Upon receipt of this message, the destination stops 917 transmitting along the protection path and de-activates the 918 LSP along this path. The de-activation procedure should 919 remove the crossed connections along the protection path 920 (and frees the resources to be used for restoring other 921 failures. 923 Administrative procedures other than reversion include the ability 924 to force a switchover (from working to protection or vice versa), 925 and locking out switchover, i.e., preventing an LSP from moving from 926 working to protection administratively. These administrative 927 conditions have to be supported by signaling. 929 6. Discussion 931 6.1 LSP Priorities During Protection 933 Under span protection, a failure event could affect more than one 934 working link and there could be fewer protection links than the 935 number of failed working links. Furthermore, a working link may 937 Lang, J., Rajagopalan, B., et al - Standards Track 17 938 contain multiple LSPs of varying priority. Under this scenario, a 939 decision must be made as to which working links (and therefore LSPs) 940 should be protected. This decision MAY be based on LSP priorities. 942 In general, a node might detect failures sequentially, i.e., all 943 failed working links may not be detected simultaneously, but only 944 sequentially. In this case, as per the proposed signaling 945 procedures, LSPs on a working link MAY be switched over to a given 946 protection link, but another failure (of a working link carrying 947 higher priority LSPs) may be detected soon afterwards. In this case, 948 the new LSPs may bump the ones previously switched over the 949 protection link. 951 In the case of end-to-end shared mesh restoration, priorities MAY be 952 implemented for allocating shared link resources under multiple 953 failure scenarios. As described in Section 4.3, more than one LSP 954 can claim shared resources under multiple failure scenarios. If such 955 resources are first allocated to a lower priority LSP, they MAY have 956 to be reclaimed and allocated to a higher priority LSP. 958 7. Security Considerations 960 There are number of security threats that MAY be experienced due to 961 the exchange of messages and information as detailed in this 962 document. Some examples include interception, spoofing, modification 963 and replay of control messages. Therefore, following security 964 requirements are applicable to the mechanisms of this document. 965 o Signaling MUST be able to provide authentication, integrity, 966 and protect against replay attacks. 967 o Privacy and confidentiality is not required. Only 968 authentication is required to ensure that the signaling 969 messages are originating from the right place and have not 970 been modified in transit. 971 o Protection of the identity of the data plane end-points (in 972 failure indication messages) is not required 974 The consequences of poorly secured protection may increase the risk 975 of triggering recovery actions under false failure indication 976 messages including LSP identifiers that are not under failure. Such 977 information could subsequently trigger initiation of "false" 978 recovery actions while there are no reasons to do so. Additionally, 979 if the identification of the LSP is tampered from a failure 980 indication message recovery actions will involve nodes for which the 981 LSPs do not indicate any failure condition or for which no failure 982 indication message has been received. The consequences of such 983 actions is unpredictable and MAY lead to de-synchronisation between 984 the control and the data plane but also increase the risk of 985 misconnections. Moreover, the consequences of poorly applied 986 protection may increase the risk of misconnection. In particular, 987 when Extra Traffic is involved, it is easily possible to deliver the 988 wrong traffic to wrong destination. Similarly, an intrusion that 989 sets up what appears to be a valid protection LSP and then causes a 990 fault may be able to divert traffic. 992 Lang, J., Rajagopalan, B., et al - Standards Track 18 993 Moreover, tampering with routing information exchange may also have 994 an effect on traffic engineering. Therefore, any mechanisms used for 995 securing and authenticating the transmission of routing information 996 SHOULD be applied in the present context. 998 8. IANA Considerations 1000 This document defines no new code points and requires no action by 1001 IANA. 1003 9. Editors' Addresses 1005 Jonathan P. Lang 1006 Sonos, Inc. 1007 506 Chapala Street 1008 Santa Barbara, CA 93101 1009 EMail: jplang@ieee.org 1011 Bala Rajagopalan 1012 Intel Broadband Wireless Div. 1013 2111 NE 25th Ave. 1014 Hillsboro, OR 97124 1015 Phone: +1 503 712-9291 1016 EMail: bala.rajagopalan@intel.com 1018 Dimitri Papadimitriou 1019 Alcatel 1020 Francis Wellesplein, 1 1021 B-2018 Antwerpen, Belgium 1022 Phone: +32 3 240-8491 1023 EMail: dimitri.papadimitriou@alcatel.be 1025 10. References 1027 10.1 Normative References 1029 [BUNDLE] Kompella, K., Rekhter, Y. and Berger, L., "Link 1030 Bundling in MPLS Traffic Engineering", draft-ietf-mpls- 1031 bundle-06.txt (work in progress). 1033 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 1034 Extensions in Support of Generalized MPLS", draft-ietf- 1035 isis-gmpls-extensions-16.txt (work in progress). 1037 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 1038 Extensions in Support of Generalized MPLS", draft-ietf- 1039 ccamp-ospf-gmpls-extensions-09.txt (work in progress). 1041 [LMP] Lang, J., Ed., "Link Management Protocol (LMP) v1.0", 1042 Internet Draft, draft-ietf-ccamp-lmp-10.txt (work in 1043 progress). 1045 [RFC2026] Bradner, S., "The Internet Standards Process -- 1046 Revision 3", BCP 9, RFC 2026, October 1996. 1048 Lang, J., Rajagopalan, B., et al - Standards Track 19 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, March 1997. 1053 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 1054 Switching (GMPLS) - Signaling Functional Description," 1055 RFC 3471, January 2003. 1057 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 1058 RFC 3667, February 2004. 1060 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 1061 Technology", BCP 79, RFC 3668, February 2004. 1063 10.2 Informative References 1065 [TERM] Mannie, E., Papadimitriou, D., Ed., "Recovery 1066 (Protection Internet Draft, draft-ietf-gmpls-recovery- 1067 terminology-06.txt, (work in progress). 1069 Lang, J., Rajagopalan, B., et al - Standards Track 20 1070 Intellectual Property Statement 1072 The IETF takes no position regarding the validity or scope of any 1073 Intellectual Property Rights or other rights that might be claimed 1074 to pertain to the implementation or use of the technology described 1075 in this document or the extent to which any license under such 1076 rights might or might not be available; nor does it represent that 1077 it has made any independent effort to identify any such rights. 1078 Information on the procedures with respect to rights in RFC 1079 documents can be found in BCP 78 and BCP 79. 1081 Copies of IPR disclosures made to the IETF Secretariat and any 1082 assurances of licenses to be made available, or the result of an 1083 attempt made to obtain a general license or permission for the use 1084 of such proprietary rights by implementers or users of this 1085 specification can be obtained from the IETF on-line IPR repository 1086 at http://www.ietf.org/ipr. 1088 The IETF invites any interested party to bring to its attention any 1089 copyrights, patents or patent applications, or other proprietary 1090 rights that may cover technology that may be required to implement 1091 this standard. Please address the information to the IETF at 1092 ietf-ipr@ietf.org. 1094 Disclaimer of Validity 1096 This document and the information contained herein are provided on 1097 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1098 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1099 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1100 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1101 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1102 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1104 Copyright Statement 1106 Copyright (C) The Internet Society (2005). This document is subject 1107 to the rights, licenses and restrictions contained in BCP 78, and 1108 except as set forth therein, the authors retain all their rights. 1110 Acknowledgment 1112 Funding for the RFC Editor function is currently provided by the 1113 Internet Society. 1115 Lang, J., Rajagopalan, B., et al - Standards Track 21