idnits 2.17.1 draft-ietf-pwe3-static-pw-status-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to indicate that this document updates RFC5885, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2011) is 4543 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: 'RFCXXXX' is mentioned on line 455, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft George Swallow 4 Intended status: Standards Track Giles Heron 5 Expires: May 15, 2012 Cisco 6 Matthew Bocci 7 Alcatel-Lucent 9 November 15, 2011 11 Pseudowire Status for Static Pseudowires 13 draft-ietf-pwe3-static-pw-status-10.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and 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 15, 2010 38 Abstract 40 This document specifies a mechanism to signal Pseudowire (PW) status 41 messages using an PW associated channel (ACh). Such a mechanism is 42 suitable for use where no PW dynamic control plane exits, known as 43 static PWs, or where a Terminating Provider Edge (T-PE) needs to send 44 a PW status message directly to a far end T-PE. The mechanism allows 45 PW OAM message mapping and PW redundancy to operate on static PWs. 46 This document also updates rfc5885 in the case when Bi-directional 47 Forwarding Detection (BFD) is used to convey PW status signaling 48 information. 50 Table of Contents 52 1 Specification of Requirements ........................ 2 53 2 Introduction ......................................... 3 54 3 Terminology .......................................... 3 55 4 Applicability ........................................ 3 56 5 Pseudowire Status Operation .......................... 4 57 5.1 PW OAM Message ....................................... 4 58 5.2 Sending a PW Status Message .......................... 5 59 5.3 PW OAM status message transmit and receive ........... 6 60 5.3.1 Acknowledgment of PW status .......................... 7 61 5.4 MPLS Label Stack ..................................... 7 62 5.4.1 Label stack for a message destined to the next PE .... 7 63 5.4.2 Label stack for a message destined to the egress PE .. 8 64 5.5 S-PE bypass mode ..................................... 8 65 5.5.1 S-PE bypass mode LDP flag bit ........................ 9 66 6 S-PE operation ....................................... 10 67 6.1 Static PW to another Static PW ....................... 10 68 6.2 Dynamic PW to Static PW or vice versa ................ 10 69 7 Security Considerations .............................. 11 70 8 IANA Considerations .................................. 11 71 9 References ........................................... 12 72 9.1 Normative References ................................. 12 73 9.2 Informative References ............................... 12 74 10 Authors' Addresses ................................... 13 76 1. Specification of Requirements 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 The default control plane for Pseudowire (PW) technology, as defined 85 in [RFC4447], is based on Label Distribution Protocol (LDP). However 86 that document also describes a static provisioning mode without a 87 control plane. When a static PW is used, there is no method to 88 transmit the status of the PW, or attachment circuit (AC) between the 89 two Provider Edge (PE) devices at each end of the PW. This document 90 defines a method to transport the PW status codes defined in 91 [RFC4447], sec 5.4.2, and elsewhere [REDUNDANCY] in-band with the PW 92 data using a generic associated channel [RFC5586]. 94 3. Terminology 96 FEC: Forwarding Equivalence Class 98 LDP: Label Distribution Protocol 100 LSP: Label Switching Path 102 MS-PW: Multi-Segment Pseudowire 104 PE: Provider Edge 106 PW: Pseudowire 108 SS-PW: Single-Segment Pseudowire 110 S-PE: Switching Provider Edge Node of MS-PW 112 T-PE: Terminating Provider Edge Node of MS-PW 114 4. Applicability 116 As described in [RFC4447] and [RFC6310], a PE that establishes an 117 MPLS PW using means other than LDP, e.g., by static configuration, 118 MUST support some alternative method of status reporting. The 119 procedures described in this document are for use when PWs are 120 statically configured and a LDP control plane is not available. 122 As defined in [RFC4447], a PE that establishes a PW using LDP MUST 123 use the PW status TLV mechanism for AC and PW status and defect 124 notification on that PW. In order to avoid duplicate notifications 125 and potentially conflicting notifications, such PEs MUST NOT use the 126 mechanisms described in this document for those PWs, except that the 127 'S-PE' bypass mode described in Section 5.5 MAY be used when both T- 128 PE at each end of the PW use LDP to establish the PW. 130 In order to protect against duplicate notifications and potentially 131 conflicting notifications, when the Pseudowire Status protocol for 132 Static Pseudowires described in this document is used, the BFD-VCCV 133 status signaling mechanisms described in [RFC5885] (CV Types 0x08 and 134 0x20) MUST NOT be used. VCCV-BFD Connectivity Verification (CV) for 135 fault detection (CV types 0x04 and 0x10) MAY still be used. 137 5. Pseudowire Status Operation 139 5.1. PW OAM Message 141 The PW status TLV as defined in [RFC4447] sec 5.4.2 is transported in 142 a PW OAM message using the PW associated channel (ACH). 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Refresh Timer | TLV Length |A| Flags | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 ~ TLVs ~ 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: ACH PW OAM Message Packet Header. 157 The first 32 bits are the standard ACH header construct as defined in 158 [RFC5586]. 160 The first nibble (0001b) indicates the ACH instead of PW data. The 161 version and the reserved values are both set to 0 as specified in 162 [RFC4385]. 164 The refresh timer is an unsigned integer and specifies refresh time 165 in seconds with a range from 1 to 65535. The value 0 means that the 166 refresh timer is set indefinitely, and the PW OAM message will never 167 be refreshed, and will never timeout. 169 The TLV length field indicates the length of all TLVs only. This 170 document defines the only the PW status TLV as defined in [RFC4447] 171 sec 5.4.2 is transported in TLV field. In the future additional TLVs 172 may be defined to be used in this field with code points allocated 173 from the IANA registry called "LDP TLV Type Name Space". 175 The A flag bit is used to indicate an acknowledgment of the PW status 176 TLV included. The rest of the flag bits are reserved and they MUST be 177 set to 0 on transmit, and ignored upon receive. When the A bit is 178 set, the refresh timer value is a requested timer value. 180 The PW OAM Message code point value is 0xZZ. [RFC Editor: 0xZZ to be 181 assigned by IANA from the PW Associated Channel Type registry.] 183 5.2. Sending a PW Status Message 185 The PW Status messages are sent in-band using the PW OAM message 186 containing the PW Status TLV, for a particular PW, as defined in 187 [RFC4447]. The PW Status TLV format almost as defined in [RFC4447], 188 and is repeated here for the reader's convenience: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |Res| PW Status (0x096A) | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Status Code | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: PW Status TLV Format. 199 Unlike the case in [RFC4447], here the first 2 bits are reserved, and 200 MUST be set to zero on transmit, and ignored on receive. 202 The PW Status TLV is prepended with an PW OAM message header and sent 203 on the ACH of the PW to which the status update applies. 205 To clear a particular status indication, the PE needs to send a new 206 PW OAM message containing a PW Status TLV with the corresponding bit 207 cleared as defined in [RFC4447]. 209 The procedures described in [RFC6073] that apply to an S-PE and PW 210 using an LDP control plane also apply when sending PW status using 211 the PW OAM channel. The OPTIONAL procedures using the SP-PE TLV 212 described in [RFC6073] can also be applied when sending PW status 213 using the PW OAM channel. 215 The detailed message transmit, and receive procedures are specified 216 in the next section. PW OAM Status Messages MUST NOT be used as a 217 connectivity verification method. 219 5.3. PW OAM status message transmit and receive 221 Unlike the PW status procedures defined in [RFC4447] with this method 222 there is no TCP/IP session, or session management. Therefore unlike 223 the TCP/IP case, where each message is sent only once, the PW OAM 224 message containing the PW status TLV needs to be transmitted 225 repeatedly to ensure reliable message delivery. If a malformed TLV, 226 or an unknown TLV is received in an PW OAM status message, the TLV 227 MUST be ignored, and the PE SHOULD report the event to the operator. 229 A PW OAM message containing a PW status TLV with a new status bit set 230 or reset, will be transmitted immediately by the PE. Unless the 231 message is acknowledged within a second, the PW OAM message will then 232 be repeated twice more at an initial interval of one second. 233 Subsequently the PW OAM message will be transmitted with an interval 234 specified by the refresh timer value in the packet. Note that this 235 value MAY be updated in the new PW OAM message packet, in which case 236 the new refresh timer value becomes the new packet transmit interval. 238 The suggested default value for the refresh timer is 30 seconds. This 239 default is adeguate for typical deployments, and PEs are designed to 240 take into account processing these messages at the required rate. 242 When a PW OAM message containing a status TLV is received, a timer is 243 started according to the refresh rate specified in the packet. If 244 another non zero PW status message is not received within 3.5 times 245 the specified timer value, the status condition will timeout in 3.5 246 times the last refresh timer value received, and the default status 247 of zero is assumed on the PW. It is also a good practice to 248 introduce some jitter in the delay between refresh transmissions, as 249 long as the maximum jitter delay is within the prescribed maximum 250 refresh time of 3.5 times the specified timer value for 3 consecutive 251 refresh packets. 253 To clear a particular status fault the PE need only send an updated 254 message with the corresponding bit cleared. If the PW status code is 255 zero, the PW OAM message will be sent like any other PW OAM status 256 message using the procedures described above, however it MUST be 257 acknowledged with a packet with a timer value of zero. This will 258 cause the PE sending the PW status notification message with PW 259 status code equal to zero to stop sending, and to continue normal 260 operation. 262 5.3.1. Acknowledgment of PW status 264 The PE receiving a PW OAM message containing a PW status message can 265 acknowledge the PW status message by simply building an almost 266 identical reply packet with the A bit set, and transmitting it on the 267 PW ACH back to the source of the PW status message. The timer value 268 set in the reply packet SHOULD then be used by the PE as the new 269 transmit interval. If the transmitting PE does not want to use the 270 new timer value (for local policy reasons, or because it simply 271 cannot support it) it MUST refresh the PW OAM message with the timer 272 value it desires. The receiving PE will then set its timeout timer 273 according to the timer value that is in the packet received, 274 regardless of what timer value it sent. The receiving PE MUST NOT 275 retry to set the timer value more then once per timer value. 277 The suggested default value for the refresh timer value in the 278 acknowledgment packet is 600 seconds. 280 If the sender PE receives an acknowledgment message that does not 281 match the current active PW status message being sent, it simply 282 ignores the acknowledgment packet. 284 If a PE that has a non zero status code for a particular PW, detects 285 by any means that the peer PE has become unreachable, it will follow 286 the standard procedures [RFC4447] and consider that PW as having an 287 additional status bit set. This would normally trigger sending 288 updates again, and canceling the acknowledgment refresh timer state. 290 5.4. MPLS Label Stack 292 With one exception, all PW OAM status messages are are sent to the 293 adjacent PE across the PSN tunnel. In many cases the transmitting PE 294 has no way to determine whether the adjacent PE is a S-PE, or a T-PE. 295 This is a necessary behavior to preserve backward compatibility with 296 PEs that do not understand MS-PWs. In the procedures described in 297 this document there are two possible destinations for the PW OAM 298 status messages: the adjacent PE, or the T-PE. Sending a PW status 299 message directly to the T-PE is a enhanced method that is only 300 applicable using PW OAM status messages sent in the PW ACH. 302 5.4.1. Label stack for a message destined to the next PE 304 A PE that needs to forward a PW OAM status message to the adjacent PE 305 across the PSN tunnel, MUST set the PW label TTL field to 1. 306 Furthermore if the control word is not in use on the particular PW, 307 the PE MUST also place the GAL reserved label [RFC5586], below the PW 308 label also with the TTL field set to 1. 310 5.4.2. Label stack for a message destined to the egress PE 312 This is also known as "S-PE bypass mode" see below. A T-PE that 313 requires sending a PW OAM status message directly to the 314 corresponding T-PE at the other end of the PW MUST set the TTL of the 315 PW label to a value that is sufficient to reach the corresponding T- 316 PE. This value will be greater then one, but will be set according to 317 the local policy on the transmitting T-PE. Furthermore if the control 318 word is not in use on the particular PW, the PE MUST also place the 319 GAL reserved label [RFC5586], below the PW label with the TTL field 320 set to 1. 322 5.5. S-PE bypass mode 324 S-PE bypass mode enables a T-PE that uses LDP as the pw setup and 325 control protocol, to bypass all S-PEs that might be present along the 326 MS-PW and to send a message directly to the remote T-PE. This is used 327 for very fast message transmission in-band with the PW PDUs. This 328 mode is OPTIONAL, and MUST be supported by both T-PEs to be enabled. 329 This mode MUST NOT be used if the first PW segment connected to each 330 T-PE is not using LDP. 332 Note that this method MUST NOT be used to send messages which are 333 permitted to originate at an S-PE, since otherwise race conditions 334 could occur between messages sent via the control plane by S-PEs, and 335 messages sent via the data plane by T-PEs. 337 Status codes, except for those listed below, MUST NOT be sent using 338 the S-PE bypass procedure: 340 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 341 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 342 0x00000020 - PW forwarding standby 343 0x00000040 - Request switchover to this PW 345 Note that since "clear all failures" may be sent by an S-PE it MUST 346 NOT be sent using the S-PE bypass mode. 348 When S-PE bypass mode is enabled, all PW Status TLVs received using 349 this method have priority over PW Status TLVs sent via control 350 protocols such as LDP [RFC4447]. However the same PW Status TLVs MUST 351 also be sent in LDP to keep the S-PEs state updated. 353 5.5.1. S-PE bypass mode LDP flag bit 355 When a PW Segment along an MS-PW is using the LDP control protocol 356 wishes to request the use of the S-PE bypass status message mode, it 357 sets the B bit in the generic protocol flags interface parameters 358 sub-TLV as shown in Figure 3. This flag can only be set by a T-PE 359 using LDP as the PW configuration and management protocol. If the S- 360 PE bypass mode LDP flag bit in the generic protocol flags interface 361 parameter does not mach in the FEC advertisement for directions of a 362 specific PW, that PW MUST NOT be enabled. 364 The interface parameter is defined as follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type=0X16 | Length=4 |R R R R R R R R R R R R R R R B| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3. PW Generic Protocol Flags sub-TLV. 373 - TLV Type. 375 Type 0x16 - PW Generic Protocol Flags. Note: Value 0x16 376 suggested for assignment pending IANA allocation. 378 - Length 380 TLV length always 4 octets. 382 - Flags 384 Bit B, in position 31 above, is set to request the S-PE bypass 385 mode. Bits R are to be allocated by IANA as described in the IANA 386 section. If they are not allocated they are to be considered as 387 reserved for future use and MUST be zero on transmission, and 388 ignored on reception of this TLV. 390 If the T-PE receives an LDP label mapping message containing a 391 generic protocol flags interface parameter TLV with the bit "B" set, 392 then the T-PE receiving the label mapping message MAY send S-PE 393 bypass status messages in the G-ACH. If Bit "B" of said TLV, is not 394 set, or the TLV is not present, then the T-PE receiving the label 395 mapping message MUST NOT send S-PE bypass status messages in the G- 396 ACH. 398 6. S-PE operation 400 The S-PE will operate according to the procedures defined in 401 [RFC6073]. The following additional procedures apply to the case 402 where a static PW segment is switched to a dynamic PW segment that 403 uses LDP, and the case a static PW segment is switched to another 404 static PW segment. 406 6.1. Static PW to another Static PW 408 The procedures that are described in [RFC6073] section 10 also apply 409 to the case of a static PW switched to another static PW. The LDP 410 header is simply replaced by the PW OAM header, otherwise the packet 411 format will be identical. The information that is necessary to form a 412 SP-PE TLV MUST be configured in the S-PE, or no SP-PE TLV will be 413 sent. The Document [RFC6073] defines a IANA registry named 414 "Pseudowire Switching Point PE TLV Type". In order to support the 415 static PW configuration and addressing scheme, a new code point is 416 requested as follows: 418 Type Length Description 419 0x07 24 Static PW/MPLS-TP PW segment ID of last 420 PW segment traversed 422 The format of this TLV is that of the "Static Pseudowire Sub-TLV" 423 defined in [ON DEMAND]. 425 6.2. Dynamic PW to Static PW or vice versa 427 The procedures that are described in [RFC6073] section 10 also apply 428 to this situation. However if the PW label of the LDP controlled PW 429 segment is withdrawn, by the adjacent PE, the S-PE will set the PW 430 status code "0x00000001 - Pseudowire Not Forwarding" to the adjacent 431 PW on the static PW segment. 433 The S-PE will only withdraw its label for the dynamic, LDP 434 controlled, PW segment if the S-PE is un-provisioned. 436 7. Security Considerations 438 The security measures described in [RFC4447], [RFC5085] and [RFC6073] 439 are adequate for the proposed mechanism. 441 8. IANA Considerations 443 IANA has to set up the registry of "PW Generic Protocol Flags". These 444 are bit strings of length 16. Bit 0 is defined in this document. Bits 445 1 through 15 are to be assigned by IANA using the "IETF consensus" 446 policy defined in [RFC5226]. 448 Any requests for allocation from this registry require a description 449 of up to 65 characters. 451 Initial PW Generic Protocol Flags value allocations are as follows: 453 Bit Mask Description 454 ==================================================================== 455 0x0001 - S-PE bypass mode [RFCXXXX] 457 This document uses a new Associated Channel Type. IANA already 458 maintains a registry of name "Pseudowire Associated Channel Types". A 459 value of 0x0022 is suggested for assignment with TLVs. The 460 description is "PW OAM Message". 462 This document uses a new Pseudowire Switching Point PE TLV Type. IANA 463 already maintains a registry of name "Pseudowire Switching Point PE 464 Sub-TLV Type". A value of 0x07 is suggested for assignment. The 465 description is "Static PW/MPLS-TP PW segment ID of last PW segment 466 traversed". 468 This document uses a new interface parameter type. IANA already 469 maintains a registry of name "Pseudowire Interface Parameters Sub-TLV 470 type Registry". A value of 0x16 is suggested for assignment. The 471 description is "PW Generic Protocol Flags". 473 9. References 475 9.1. Normative References 477 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing 478 an IANA Considerations Section in RFCs", RFC 5226, May 2008 480 [RFC5085] T. Nadeau, Ed., C. Pignataro, Ed., "Pseudowire 481 Virtual Circuit Connectivity Verification (VCCV): 482 A Control Channel for Pseudowires", RFC5085, December 2007 484 [RFC2119] Bradner. S, "Key words for use in RFCs to 485 Indicate Requirement Levels", RFC 2119, March, 1997. 487 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 488 et al., rfc4447 April 2006. 490 [RFC6073] Martini et.al. "Segmented Pseudowire", 491 RFC 6073, January 2011. 493 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 494 Control Word for Use over an MPLS PSN", S. Bryant, et al., 495 RFC4385, February 2006. 497 [ON DEMAND] Bahadur et.al. "MPLS on-demand Connectivity 498 Verification, Route Tracing and Adjacency Verification", 499 draft-ietf-mpls-tp-on-demand-cv-07.txt, IETF Work in Progress, 500 September 2011 502 [RFC6310] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, 503 T. Nadeau, Y(J). Stein, "Pseudowire (PW) Operations, 504 Administration, and Maintenance (OAM) Message Mapping", 505 RFC6310, July 2011 507 9.2. Informative References 509 [REDUNDANCY] Muley et.al. "Preferential Forwarding Status 510 bit definition", draft-ietf-pwe3-redundancy-bit-05.txt, 511 IETF Work in Progress, September 2011. 513 [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., 514 "MPLS Generic Associated Channel", rfc5586, June 2009 516 [RFC5885] T. Nadeau, Ed.,C. Pignataro, Ed., "Bidirectional 517 Forwarding Detection (BFD) for the Pseudowire Virtual 518 Circuit Connectivity Verification (VCCV)", RFC5885, June 2010. 520 10. Authors' Addresses 522 Luca Martini 523 Cisco Systems, Inc. 524 9155 East Nichols Avenue, Suite 400 525 Englewood, CO, 80112 526 e-mail: lmartini@cisco.com 528 George Swallow 529 Cisco Systems, Inc. 530 300 Beaver Brook Road 531 Boxborough, Massachusetts 01719 532 United States 533 e-mail: swallow@cisco.com 535 Giles Heron 536 Cisco Systems 537 9-11 New Square 538 Bedfont Lakes 539 Feltham 540 Middlesex 541 TW14 8HA 542 United Kingdom 543 e-mail: giheron@cisco.com 545 Matthew Bocci 546 Alcatel-Lucent 547 Grove House, Waltham Road Rd 548 White Waltham, Berks, UK. SL6 3TN 549 e-mail: matthew.bocci@alcatel-lucent.co.uk 551 Copyright Notice 553 Copyright (c) 2011 IETF Trust and the persons identified as the 554 document authors. All rights reserved. 556 This document is subject to BCP 78 and the IETF Trust's Legal 557 Provisions Relating to IETF Documents 558 (http://trustee.ietf.org/license-info) in effect on the date of 559 publication of this document. Please review these documents 560 carefully, as they describe your rights and restrictions with respect 561 to this document. Code Components extracted from this document must 562 include Simplified BSD License text as described in Section 4.e of 563 the Trust Legal Provisions and are provided without warranty as 564 described in the Simplified BSD License. 566 Expiration Date: May 2012