idnits 2.17.1 draft-boutros-mpls-tp-cv-01.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.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 159 has weird spacing: '...ing the codep...' -- The document date (March 9, 2009) is 5517 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) ** Obsolete normative reference: RFC 4379 (ref. '2') (Obsoleted by RFC 8029) == Outdated reference: A later version (-03) exists of draft-boutros-mpls-tp-loopback-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-00 == Outdated reference: A later version (-02) exists of draft-bryant-mpls-tp-ach-tlv-00 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-gach-gal-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros (Ed.) 3 Internet Draft Siva Sivabalan (Ed.) 4 Intended status: Standards Track George Swallow 5 Expires: September 2009 David Ward 6 Stewart Bryant 7 Cisco Systems, Inc. 9 March 9, 2009 11 Connection verification for MPLS Transport Profile LSP 12 draft-boutros-mpls-tp-cv-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on September 9, 2009. 37 Abstract 39 This document specifies method for verifying the connection of an 40 MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for 41 management purpose. The proposed extension is based on MPLS 42 Operation, Administration, and Maintenance (OAM). The goal is to 43 verify that an MPLS-TP is properly setup in both control and data 44 planes, as well as to record the identities of all the LSRs along the 45 path of MPLS-TP LSP. 47 Table of Contents 49 1. Introduction...................................................2 50 2. Terminology....................................................4 51 3. MPLS-TP Connection Verification Mechanism......................5 52 4. MPLS-OAM Connection Verification Message.......................5 53 4.1. In-band Message Identification............................5 54 4.2. Out-of-band Message Identification........................6 55 4.3. MPLS-TP CV Message Format.................................6 56 4.4. MPLS-TP Connection Verification Record Route TLV.........10 57 4.5. Network Management System................................10 58 5. Operation.....................................................10 59 6. Security Considerations.......................................12 60 7. IANA Considerations...........................................12 61 8. References....................................................13 62 8.1. Normative References.....................................13 63 8.2. Informative References...................................13 64 Author's Addresses...............................................14 65 Full Copyright Statement.........................................15 66 Intellectual Property Statement..................................15 68 1. Introduction 70 In traditional transport networks, circuits are provisioned on 71 multiple switches. Service Providers (SP) need to verify that the 72 circuits are provisioned correctly in both control and data plane for 73 management purpose. MPLS-TP bidirectional LSPs emulating traditional 74 transport circuits need to provide the same connection verification 75 capability. In this document, an MPLS-TP LSP as defined in [5] is 76 based on the MPLS-TE, pseudowire (PW) or Multisegment PW [8]. 78 An MPLS-OAM Connection Verification (CV) message originates at a 79 Maintenance End Point (MEP) but can be directed to by any Maintenance 80 Intermediate Point (MIP) along the path of MPLS-TP LSP as well as the 81 other MEP. Therefore, the proposed mechanism addresses the 82 verification of the full or partial path of an MPLS-TP LSP. 84 An MPLS-OAM CV message is intercepted at any MIP based on MPLS TTL 85 expiry, and at MEP simply because it is the end of the LSP (i.e., 86 regardless the value of the TTL). 88 In response to the MPLS-OAM CV request, each LSR along the path of 89 the MPLS-TP LSP appends its ID using a newly defined TLV called 90 Record Route TLV. 92 A Record Route TLV appended by a given LSR contains: 94 . The LSR address which is represented by the format defined in 95 [6]. 97 . Local Labels allocated by the LSR for both directions of the 98 MPLS-TP LSP. 100 To describe the connection verification functionality, let us assume 101 an MPLS-TP LSP between LSR-1 and LSR-5 passing through LSR-2, LSR-3, 102 and LSR-4. Thus, LSR-1 and LSR-5 are MEPs whereas LSR-2, LSR-3, and 103 LSR-4 are MIPs. The objective is to verify (both in control and data 104 planes) the MPLS-TP LSP from LSR-1 to LSR-5 (end-to-end), and record 105 all the IDs of the LSRs along the path. This could be accomplished 106 using a conventional traceroute operation in which LSR-1 interrogates 107 each LSR-2 through LSR-5 (using appropriate TTL value) in turn using 108 a new message and response, and compiles the result. This approach 109 requires 8 messages; a request and a response between LSR-1 and each 110 of the other LSRs. On the other hand, the mechanism that we describe 111 below can accomplish the goal with only 5 messages. 113 It is possible that the path of an MPLS-TP LSP contains loop(s) due 114 to misconfiguration. Such mistakes are possible with manual 115 configuration. For example, assume that MPLS-TP LSP under discussion 116 is misconfigured such LSR-4 connects to LSR-2 instead of LSR-5. This 117 results in a loop. In this case, the MPLS-OAM CV packets self limit 118 when the MTU is reached, and when it happens, it is good practice to 119 silently drop those packets. 121 If a MIP does not understand the MPLS-OAM CV message, it must 122 silently drop the packet. To trap this condition as well as to trap 123 the looping condition, an ingress MEP that initiates connection 124 verification starts a timer when it sends an MPLS-OAM CV message. If 125 the timer expires before the response arrives, the MEP assumes one of 126 the following conditions: 128 . the MPLS-TP LSP is incomplete. 130 . an LSR (either MIP or MEP) does not understand the MPLS-OAM CV 131 message. 133 . there is a loop. 135 The ingress MEP then examines the MPLS-TP LSP by using the classic 136 one-hop at a time, direct response traceroute. 138 In case not all hops on the path of the MPLS-TP LSP are MIPs, an 139 ingress MEP can send conventional trace route with incrementing TTL 140 1, 2, 3, ...., to all MIPs and to the egress MEP along the path. Some 141 of those requests will be sent to non MIP/MEP LSRs and will be 142 dropped silently. When the MIPs and egress MEP receive the request, 143 they will respond with an MPLS-OAM CV response message. The TTL value 144 of the response SHOULD be large to ensure the response message 145 reaches the ingress MEP without being intercepted at any MIP. 146 Optionally, the TTL value of the response MAY be set to 1 so that 147 each MIP can verify its ID included in the response message as the 148 response travels towards the ingress MEP. 150 The proposed mechanism is based on a set of new TLVs which can be 151 transported using one of the following methods: 153 1. Using in-band MPLS Connection Verification (CV) messages which 154 are forwarded as MPLS packets (Non-IP routing and forwarding 155 based). 157 2. Using in-band LSP-Ping extensions defined in [2] where IP/UDP 158 packets are used (IP-Based routing and forwarding). The LSP- 159 Ping messages may be sent in-band using the codepoint defined 160 in [3]. 162 Method (1) and (2) are referred to as "in-band option" and "LSP-Ping 163 option" respectively in the rest of the document. 165 Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC-2119 Error! 170 Reference source not found. 172 2. Terminology 174 ACH: Associated Channel Header 176 CV: Connection Verification 178 GAL: Generalized Alert Label 179 LSR: Label Switching Router 181 MEP: Maintenance End Point 183 MIP: Maintenance Intermediate Point 185 MPLS-OAM: MPLS Operations, Administration and Maintenance 187 MPLS-TP: MPLS Transport Profile 189 MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit 191 MS-PW: Mult-Segment PseudoWire 193 NMS: Network Management System 195 PW: PseudoWire 197 RR: Record Route 199 TLV: Type Length Value 201 TTL: Time To Live 203 3. MPLS-TP Connection Verification Mechanism 205 For the in-band option, the proposed mechanism uses a new code point 206 in the Generic Associated Channel Header (G-ACH) described in [7]. 207 The LSP-Ping option will be in compliance to specifications [2] and 208 [3]. 210 Moreover, the proposed mechanism requires Record Route TLV (defined 211 in this document). Also, Authentication TLV defined in [4] is also 212 required for this mechanism. 214 4. MPLS-OAM Connection Verification Message 216 4.1. In-band Message Identification 218 In the in-band option, under MPLS label stack of the MPLS-TP LSP, the 219 ACH with "MPLS-TP Connection Verification (CV)" code point indicates 220 that the message is an MPLS-TP CV message. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |0 0 0 1|Version| Flags | 0xHH MPLS-TP CV Code Point | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 1: ACH Indication of MPLS-TP Connection Verification 230 The first nibble (0001b) indicates the ACH. The version and the 231 reserved values are both set to 0 as specified in [1]. MPLS-TP 232 Connection Verification code point = 0xHH. [HH to be assigned by IANA 233 from the PW Associated Channel Type registry.] 235 4.2. Out-of-band Message Identification 237 [To be added] 239 4.3. MPLS-TP CV Message Format 241 The format of an MPLS-TP CV Message is shown below. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Version | Message Type | Operation | Reserved | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Return Code | Cause Code | Message Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Sender's Handle | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Message ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | TLV's | 255 ~ ~ 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 2: MPLS-TP CV Message Format 260 Version 261 The Version Number is currently 1. 263 Message Type 264 The following two message types are defined: 266 Message Type Description 267 ------------ ----------- 268 0x0 CV Request 269 0x1 CV Reply 271 Operation 272 The following two operations are defined: 274 Operation Description 275 --------- ------------- 276 0x0 Only verify MPLS-TP LSP 278 0x1 Verify MPLS-TP LSP and record route 280 0x2 Verify MPLS-TP LSP, record route, and 281 verify LSR ID in the record route before 282 forwarding response 284 First, all operation codes are meanigful only in the MPLS-TP CV 285 request message, and this field currently ignored in the MPLS- 286 TP CV response message. 288 The operation code 0x0 is used to instruct a MIP or the 289 receiver MEP to simply verify the MPLS-TP LSP associated with 290 the MPLS-TP CV request message. In this case, after 291 successfully processing the request message, an LSR should 292 simply forward the message without appending Record Route TLV. 294 The operation code 0x1 is used to instruct a MIP or the 295 receiver MEP to not only verify the MPLS-TP but also append a 296 Record Route TLV to the request message if the message is 297 succesfully processed. Also, if the receiver needs to send a 298 positive reponse back to the sender, it MUST include all the 299 Record Route TLVs appended to the message by itself and all the 300 upstream LSRs. Note that if a negative response is to be sent, 301 Record Route TLVs are not appended to the response. 303 The operation code 0x2 is used to instruct a MIP receiving an 304 MPLS-TP CV request message to verify the connection and append 305 Record Route TLV. Additionally, it also instructs the LSR 306 originating the response (MIP or MEP) to set the TTL value in 307 the response such that the response will be intercepted by each 308 upstream LSR. The intention is to let each upstream LSR to 309 verify that the Record Route TLV that it appended to the 310 request message exists in the response as well. Note that such 311 verification is required only when positive response is sent. 312 To facilitate such verification, the originator of the response 313 as well as each LSR intercepting the response MUST set the TTL 314 value to 1 in the response. 316 Return code 318 Value Meaning 319 ----- ------- 320 0 Success 321 1 Failure 323 Cause code 325 Value Meaning 326 ----- ------- 327 0 No cause code 328 1 Fail to find MPLS-TP LSP 329 2 Malformed CV message received 330 3 Received unknown TLV 331 4 Authentication failed 332 5 MPLS-TP LSP not setup in downstream direction 333 6 MPLS-TP LSP not setup in upstream direction 334 7 MPLS-TP LSP not setup in both directions 335 8 LSR-ID is missing in the record route of positive 336 response 338 In the case of cause code 3, the unknown TLVs can be optionally 339 sent in the response message. Use cases of the above cause 340 codes are explained in the operation section below. 342 When MPLS-TP CV response travels back to the sender, a MIP 343 intercepting the message could check if the Record Route TLV 344 that it appended to the request exists in the response. As 345 such, the cause code 8 is meaningful only in the response 346 message. 348 Sender's Handle 349 The Sender's Handle is filled in by the sender, and remains in 350 tact as the CV request message travels. Also, this handle MUST 351 be returned unchanged in all CV response messages. There are no 352 semantics associated with this handle, although a sender may 353 find this useful for matching up request with replies. 355 Message Length 356 The total length of any included TLVs. 358 Message ID 359 The Message ID is set by the sender of the MPLS-TP CV request 360 message. It MUST be copied unchanged by any MEP or other MIP 361 both in the CV request and response message. A sender SHOULD 362 increment this value on each new message. A retransmitted 363 message SHOULD leave the value unchanged. 365 An MPLS-TP CV request message MUST contain a LSPI TLV to identify 366 the MPLS-TP LSP being verified, Source Address TLV identifying the 367 sender of the message, and Destination Address TLV identifying the 368 target receipient of the message. Note that in the successful 369 case, the MPLS-TP CV response message MUST be originated from the 370 target recipient of the request, and the target receipient can be 371 MIP or a MEP. However, in the case of negative response, the LSR 372 that fails to process the message generates the response message. 373 When sending a response, the Source Address TLV identifies the LSR 374 originating the response and the Destination Address TLV 375 identifies the intended receipient of the message (which is the 376 source of the request message). Format of these TLVs are specified 377 in [6]. Furthermore, an Authentication TLV defined in [4] can be 378 optionally included in the request message as well. 380 4.4. MPLS-TP Connection Verification Record Route TLV 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | type = TBD | Length = variable | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Upstream Label | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Downstream Label | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 ~ LSR Address ~ 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Figure 3: MPLS-TP CV Record Route TLV format 398 The Record Route TLV includes the LSR address sub-TLV defined in [6] 399 as well as the upstream and downstream labels (allocated by the LSR 400 for both directions of the LSP). The upstream label is the label 401 allocated by the LSR for the direction of the connection verification 402 request message. The label value of 0 means that a label is not 403 allocated for the respective direction. 405 Note that recording route is meaningful only if the connection 406 verification operation is successful. As such, a receiver MUST 407 examine any Record Route TLV only if the return code is 0 (success) 408 in the connection verification response message. 410 4.5. Network Management System 412 An operator should be able to provision any given LSR to send MPLS- 413 OAM CV Request packets from a MEP and notify NMS when MPLS-OAM CV 414 Response arrives. 416 [More description is to added] 418 5. Operation 420 Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <--> 421 LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective 422 direction. LSR-1 and LSR-5 are MEPs, and LSR-2 through LSR-4 are 423 MIPs. 425 The proposed mechanism operates as follows: 427 1. LSR-1 sends an MPLS-TP CV Request message where the Source Address 428 TLV, Destination Address TLV, and LSPI TLV represent LSR-1, LSR-5, 429 and the LSP being verified respectively. An Authentication TLV may 430 also be included. 432 2. The MPLS-TP CV Request message is intercepted at LSR-2 (MIP) 433 because of TTL expiry. LSR-2 then verifies the request and: 435 1. if the MPLS-TP LSP cannot be located, it sends a response with 436 return code 1 and cause code 1. 438 2. if the message is malformed, it sends a response with return 439 code 1 and cause code 2. 441 3. if any of the TLV is not known, it sends a response with 442 return code 1 and cause code 3. It may also include the 443 unknown TLVs. 445 4. if message authentication fails, it sends a response with 446 return code 4 and cause code 4. This step is valid only if an 447 Authentication TLV is present in the request. 449 5. if the MPLS-TP LSP is not setup in downstream direction, it 450 sends a response with return code 1 and cause code 5. 452 6. if the MPLS-TP LSP is not setup in upstream direction, it 453 sends a response with return code 1 and cause code 6. 455 7. if the MPLS-TP LSP is not setup in both directions, it sends a 456 response with return code 1 and cause code 7. 458 Note that MPLS TTL value is set to 255 in the response message. 459 In the response message, Source LSR address TLV is filled with 460 the address of LSR-2. 462 When LSR-1 receives the MPLS-TP CV Response, the Destination 463 Address TLV indicates that it is the intended recipient of the 464 message. Furthermore, it learns that connection verification 465 for the MPLS-TP LSP in question failed at LSR-2 by examining 466 the LSPI and Source Address TLVs respectively in the message. 468 3. If LSR-2 is able to successfully process the MPLS-TP CV Request 469 message, and if the MPLS-TP LSP is setup in both upstream and 470 downstream directions, and if the destination address in CV request 471 does not match LSR-2 address, it forwards the message to LSR-3 with 472 TTL equals 1. LSR-2 appends its address as well as the upstream and 473 downstream labels to the message if the operation code is 1 or 2. 474 Otherwise, LSR-2 simply forwards the message to LSR-3. 476 4. LSR-3 repeats the steps (2) or (3). In the absence of error, the 477 messages progresses towards LSR-5 with each LSR adding its own ID 478 and the local labels (for operation code 1 or 2). 480 5. Upon getting the MPLS-TP CV message, LSR-5 verifies the request. If 481 an MPLS-TP LSP represented by LSPI TLV in the message is found, and 482 if that MPLS-TP LSP is fully setup, LSR-5 checks the destination 483 address in the CV request and if the destination address matches 484 it's address it sends an MPLS-TP CV response with return code 0 485 (success) back to the LSR-1. If the operation code in the request 486 message is 1 or 2, LSR-5 appends all the Record Route TLVs received 487 from upstream LSRs. Otherwise, the response does not include the 488 Record Route TLVs received from the upstream LSRs. The TTL value in 489 the response can set as follows: 491 1. If the operation code in the request is 1, the TTL value is 492 set to 255 so that the response message reaches LSR-1 without 493 further interception at any other LSR. 495 2. If the operation code in the MPLS-TP CV request message is 2, 496 LSR-5 sends the response down the return path with TTL value 497 equals 1 so that an LSR intercepting the message can verify 498 its address and labels included in the response. 500 6. In case LSR-4 receives the response message, it checks if its 501 address and labels are included in the record route. If the check 502 fails, it sends an MPLS-TP CV response with return code 1 (error) 503 with cause code 8 back to LSR-1, and in this case the address of 504 LSR-4 is included in the Source Address TLV of the response. If the 505 check succeeds, LSR-4 simply forwards the message to LSR-3. 507 7. When LSR-1 receives a response with a record route, it learns the 508 address and the distance (in terms of hop count) of each LSR on the 509 path of the MPLS-TP LSP. 511 6. Security Considerations 513 The security considerations for the authentication TLV need further 514 study. 516 7. IANA Considerations 518 To be added. 520 8. References 522 8.1. Normative References 524 [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement 525 Levels", RFC 2119, March, 1997. 527 [2] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label 528 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 530 [3] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity 531 Verification (VCCV): A Control Channel for Pseudowires ", RFC 532 5085, December 2007. 534 [4] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in 535 Loopback Mode ", draft-boutros-mpls-tp-loopback-01.txt, Work in 536 Progress, December 2008. 538 8.2. Informative References 540 [5] M. Bocci, et. al., "A Framework for MPLS in Transport 541 Networks", draft-ietf-mpls-tp-framework-00.txt, Work in 542 Progress, November 2008. 544 [6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- 545 bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. 547 [7] M. Bocci, et. al., "MPLS Generic Associated Channel", draft- 548 ietf-mpls-tp-gach-gal-02.txt, work in progress, January 6, 549 2009. 551 [8] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire 552 Emulation Edge-to-Edge (PWE3)", RFC5254, October 2008. 554 Author's Addresses 556 Sami Boutros 557 Cisco Systems, Inc. 558 3750 Cisco Way 559 San Jose, California 95134 560 USA 561 Email: sboutros@cisco.com 563 Siva Sivabalan 564 Cisco Systems, Inc. 565 2000 Innovation Drive 566 Kanata, Ontario, K2K 3E8 567 Canada 568 Email: msiva@cisco.com 570 George Swallow 571 Cisco Systems, Inc. 572 300 Beaver Brook Road 573 Boxborough , MASSACHUSETTS 01719 574 United States 575 Email: swallow@cisco.com 577 David Ward 578 Cisco Systems, Inc. 579 3750 Cisco Way 580 San Jose, California 95134 581 USA 582 Email: wardd@cisco.com 584 Stewart Bryant 585 Cisco Systems, Inc. 586 250, Longwater, Green Park, 587 Reading RG2 6GB, UK 588 UK 589 Email: stbryant@cisco.com 591 Full Copyright Statement 593 Copyright (c) 2009 IETF Trust and the persons identified as the 594 document authors. All rights reserved. 596 This document is subject to BCP 78 and the IETF Trust's Legal 597 Provisions Relating to IETF Documents in effect on the date of 598 publication of this document (http://trustee.ietf.org/license-info). 599 Please review these documents carefully, as they describe your rights 600 and restrictions with respect to this document. 602 All IETF Documents and the information contained therein are provided 603 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 604 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 605 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 606 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 607 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 608 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 609 FOR A PARTICULAR PURPOSE. 611 Intellectual Property Statement 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. 620 Copies of Intellectual Property disclosures made to the IETF 621 Secretariat and any assurances of licenses to be made available, or 622 the result of an attempt made to obtain a general license or 623 permission for the use of such proprietary rights by implementers or 624 users of this specification can be obtained from the IETF on-line IPR 625 repository at http://www.ietf.org/ipr. 627 The IETF invites any interested party to bring to its attention any 628 copyrights, patents or patent applications, or other proprietary 629 rights that may cover technology that may be required to implement 630 any standard or specification contained in an IETF Document. Please 631 address the information to the IETF at ietf-ipr@ietf.org. 633 The definitive version of an IETF Document is that published by, or 634 under the auspices of, the IETF. Versions of IETF Documents that are 635 published by third parties, including those that are translated into 636 other languages, should not be considered to be definitive versions 637 of IETF Documents. The definitive version of these Legal Provisions 638 is that published by, or under the auspices of, the IETF. Versions of 639 these Legal Provisions that are published by third parties, including 640 those that are translated into other languages, should not be 641 considered to be definitive versions of these Legal Provisions. 643 For the avoidance of doubt, each Contributor to the UETF Standards 644 Process licenses each Contribution that he or she makes as part of 645 the IETF Standards Process to the IETF Trust pursuant to the 646 provisions of RFC 5378. No language to the contrary, or terms, 647 conditions or rights that differ from or are inconsistent with the 648 rights and licenses granted under RFC 5378, shall have any effect and 649 shall be null and void, whether published or posted by such 650 Contributor, or included with or in such Contribution. 652 Acknowledgment 654 Funding for the RFC Editor function is currently provided by the 655 Internet Society.