idnits 2.17.1 draft-jounay-pwe3-dynamic-pw-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 5981 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: 'N1' is mentioned on line 479, but not defined == Missing Reference: 'P1' is mentioned on line 479, but not defined == Missing Reference: 'N2' is mentioned on line 480, but not defined == Missing Reference: 'P2' is mentioned on line 480, but not defined == Missing Reference: 'N' is mentioned on line 478, but not defined == Missing Reference: 'P' is mentioned on line 478, but not defined == Unused Reference: 'RFC2119' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC4234' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-03 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Jounay 3 Internet Draft P. Niger 4 Category: Standards Track France Telecom 5 Expires: May 2008 6 Y(J) Stein 7 RAD Data 8 Communications 10 H. Shah 11 Ciena Corp 13 November 12, 2007 15 Dynamic Update of PW Parameters 17 draft-jounay-pwe3-dynamic-pw-update-00.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This draft aims at providing a generic solution for updating PW 45 characteristics (interface parameters, label) on-the-fly without 46 service interruption. The document specifies a new generic PWE 47 control protocol mechanism called the PW Update. A PW Update LDP 48 sub-TLV is defined for that purpose. It defines the signaling 49 extension and describes the procedures to dynamically update the PW 50 parameters. A use case is provided for CESoPSN PWs. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119. 58 Table of Contents 60 1. Terminology.....................................................3 61 2. Introduction....................................................3 62 3. Motivation......................................................3 63 4. Overview of the solution........................................3 64 5. PW Update LDP TYPE TLV..........................................5 65 6. Generic PW Capacity Update......................................6 66 6.1. Update Procedure............................................6 67 6.2. PW Update Mechanism Reference Model.........................7 68 6.3. Control Plane...............................................7 69 6.4. Data Plane..................................................8 70 7. Use Case: CESoPSN...............................................8 71 7.1. Interface Parameters for CESoPSN PWs................... ....9 72 7.1.1. CEP/TDM Payload Bytes (0x04)............................9 73 7.1.2. CEP/TDM Bit-Rate (0x07).................................9 74 7.2. CESoPSN Interface Parameters Update Mechanism Reference....10 75 7.3. Control Plane..............................................10 76 7.4. Data Plane.................................................11 77 8. MS-PW Applicability............................................11 78 9. Pseudowire Update Backward Compatibility.......................11 79 10. Security Considerations.......................................12 80 11. IANA Considerations...........................................12 81 11.1. LDP TLV Type..............................................12 82 11.2. LDP PW Update Codes.......................................12 83 12. Acknowledgments...............................................12 84 13. References....................................................13 85 13.1. Normative References......................................13 86 13.2. Informative References....................................13 88 1. Terminology 90 The document uses terminology defined in [RFC4447], [PW TDM CTRL]. 92 2. Introduction 94 This draft aims at providing a generic solution for on-the-fly 95 updating of PW characteristics (interface parameters, PW label) 96 without service interruption. 97 Section 5 specifies a new LDP TYPE TLV, PW Update sub-TLV, which is 98 used to advertise the parameters (interface parameters, label..) to 99 be changed. 100 Section 6 defines the related signaling extension and describes the 101 procedures to update dynamically the PW characteristics. 102 Section 7 provides an example use-case, for CESoPSN PWs. 104 3. Motivation 106 The specification of a PW update mechanism is motivated by the need 107 to update a PW parameters, while avoiding service disruption. That 108 is particularly valuable for voice service applications, for 109 example, mobile backhauling. Although interface parameter update 110 will generally be a rare event for most applications, it is still 111 highly recommended not to negatively impact customer services. This 112 is even truer when the number of customers already in use is 113 significant. 115 Alternatives to PW parameter update are available when facing 116 traffic evolution. For instance, it would be possible to setup a new 117 PW dedicated to handle the traffic overload. However, this scenario 118 does not scale since each update would result in setting up a new 119 PW, leading to management fragmentation. 121 4. Overview of the solution 123 The proposed solution is only applicable to the Generalized PWid FEC 124 element. This is because we desire to change some of the interface 125 parameters while keeping the same PW FEC element. Note that the PWid 126 FEC element described in [RFC4447] includes the interface parameters 127 and so does not allow maintaining the FEC. The update mechanism with 128 PWid FEC element is left for further study. 130 |<-------------- Emulated Service ---------------->| 131 | | 132 | |<------- Pseudowire ------->| | 133 | | | | 134 |Attachment| |<-- PSN Tunnel -->| |Attachment| 135 | Circuit V V V V Circuit | 136 V (AC) +----+ +----+ (AC) V 137 +-----+ | | PE1|==================| PE2| | +-----+ 138 | | | | | | | | | | 139 | CE1 |----------|............PW1.............|----------| CE2 | 140 | | | | | | | | 141 +-----+ | |==================| | +-----+ 142 +----+ +----+ 143 LLM (FEC1, L1, int. Par.) 144 -----------------------> 145 LLM (FEC1, L2, int. Par.) 146 <----------------------- 148 Figure 1 Reference Model 150 Referring to Figure 1, PE1 is assumed as the ingress PE, and so 151 initiates the first LDP Label Mapping (LLM) message. PE2 is assumed 152 as the egress PE. The interface parameters included in the LLM 153 message allow the egress PE to be informed of the payload format 154 used by the ingress PE. The egress PE forwards the payload received 155 from CE2 in the appropriate format with the PW Label L1 to the 156 ingress PE. The Label L1 carries the (forwarding) semantics for the 157 ingress PE to correctly forward the traffic to CE1 over its local 158 AC. The same process applies in the reverse direction for the 159 traffic from the ingress PE to the egress PE. 161 Let's assume that some time after CE1 and CE2 have been in 162 communications, the need arises to change the traffic bandwidth. 163 This warrants a mechanism whereby operator can adjust the PW 164 capacity without incurring service disruption. We describe below how 165 the sequence of events at the control plane and data plane is 166 coordinated to bring about this capacity adjustment with no service 167 disruption. The concept employed is "make-before-break". 169 Control plane: The method consists of re-advertising the new 170 interface parameters in a new LLM message. The LLM message may also 171 carry a new label in addition to the updated interface parameters 172 for the same PW FEC element. A new LDP TLV Type is defined to 173 identify the update purpose of this LLM message, since otherwise the 174 new mapping of an already advertised FEC would be rejected. The PW 175 Update sub-TLV is included in the LLM message with the interface 176 parameters codes that are changed. The receiving PE verifies the 177 updates and acknowledges the acceptance by reciprocating the LLM 178 message to the sender. 180 Note that if the If asymmetric parameters are allowed such that 181 egress PE2 does not need to increase the b/w then there is no need 182 to acknowledge the acceptance. LLM messages are assumed accepted 183 unless corresponding LDP label release is received. 185 Data plane: Upon reception of the new LLM message the egress PE 186 sends the traffic in the new format while initiating the new LLM 187 message for the reverse direction. Note that the possible new 188 assigned Label is required to allow the ingress PE to detect in-band 189 the traffic corresponding to the new format. Therefore the ingress 190 PE is capable of forwarding traffic correctly over its local AC in 191 its new format, since it recognizes the new Label it assigned and 192 previously advertised. 194 5. PW Update LDP TYPE TLV 196 The PW Update LDP sub-TLV is included in the LLM message to identify 197 its update role, thus allowing the receiving PE to accept the new 198 interface parameters and also the possible new Label required for 199 the in-band detection. 200 The PW Update sub-TLV has the following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |1|0| PW Update Type (0x096D)| Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++ 207 | Update Code | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2 PW Update sub-TLV 212 U = 1 F= 0 implies that a legacy PE must silently discard the TLV. 214 The PW Update sub-TLV MUST be included in the Label Mapping message 215 generated by a PE to update some PW characteristics. 217 The TLV information length field contains the length of the update 218 code, namely the number of parameters to be updated in octets. Hence 219 the number of parameters to be changed included in the PW Update is 220 deduced from this field. 222 The Update Code indicates the parameters that must be updated. Two 223 update code are identified for the purpose of this document 224 (interface parameters iP, PW Label L). 226 (IANA assignment required). 228 The PW Update sub-TLV is carried as follows in the Label Mapping 229 message: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 + Generalized ID FEC + 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | PW Update TLV | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Interface Parameters | 240 | " | 241 | " | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |0|0| Generic Label (0x0200) | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Label | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3 PW Update sub-TLV in LLM 250 Note that the new values of the PW interface parameters defined in 251 [RFC4446] are indicated in the classic fields (i.e. the Interface 252 parameters sub-TLV as defined in [RFC4447]). 254 6. Generic PW Capacity Update 256 6.1. Update Procedure 258 Two possible scenarios are possible when the PW capacity is 259 renegotiated, i.e. increase or decrease the PW capacity via the 260 interface parameters. The operator must take care to configure the 261 new interface parameters while not impacting existing services. The 262 update procedure must apply as follows: 264 - Increase the PW capacity: 265 Step1: Negotiate the new interface parameters at the both PW 266 endpoints (ingress and egress PE) according to the procedure 267 described in this document. 268 Step2: Configure on CEs the new payload related to the new interface 269 parameters. 271 - Decrease the PW capacity: 272 Step1: Configure on CEs the new payload related to the new interface 273 parameters. 274 Step2: Negotiate the new interface parameters at the both PW 275 endpoints (PE1, PE2) according to the procedure described in this 276 document. 278 6.2. PW Update Mechanism Reference Model 280 +----+ +----+ 281 +-----+ | PE1|==================| PE2| +-----+ 282 | | | | | | | | 283 | CE1 |----------|............PW1.............|----------| CE2 | 284 | | | | | | | | 285 +-----+ | |==================| | +-----+ 286 +----+ +----+ 287 F1-> LLM (FEC1, L1, int. Par. [iP1,iP2]) <-F1 288 ----------------------> 289 LLM (FEC1, L2, int. Par. [iP1,iP2]) 290 <----------------------- 292 ==========L2==========> 294 <=========L1=========== 295 . 296 . 297 LLM (FEC1, L10, Update (iP, L), new int. Par. [iP1, iP2new]) 298 -----------------------. 299 <=========L10========== 300 LLM (FEC1, L20, Update (iP, L), new int. Par. [iP1, iP2new]) 301 <----------------------- 302 =========L20=========> 303 F2-> <-F2 305 Figure 4 PW Update Mechanism Reference Model 307 Figure 4 depicts the procedure to update PW interface parameters and 308 the PW label. Initially PE1, the ingress PE and egress PE has a PW 309 setup with two interface parameters iP1 and iP2 that defines how the 310 traffic received from the attached CEs must be forwarded over the PW. 312 CE1 and CE2 are sending traffic in a payload format F1. 314 Note that the mechanism reference provides the most challenging case 315 where interface parameters and PW label must be both updated. Some 316 use cases may require only to change the PW label or only to change 317 some PW interface parameters. 319 6.3. Control Plane 321 Referring to Figure 4, after the operator configures a new value 322 P2new for the interface parameter (iP2), the ingress PE sends an 323 "update" LLM message to indicate the new PW parameters to the egress 324 PE. The LLM message includes the PW Update sub-TLV that specifies 325 that the interface parameters and the Label must be updated. The LLM 326 message contains a new Label L10. 328 Upon reception of the LLM message the egress PE checks the presence 329 of the PW Update sub-TLV. If the PW Update sub-TLV is included in the 330 LLM message, the egress PE carries on the process by responding to 331 the ingress PE with a new LMM message as described in [RFC4447] with 332 the new interface parameter iP2 and a new Label L20. The value of 333 this new interface parameter correspond to the one learnt from the 334 LLM message received from the ingress PE. 336 The interface parameters could be different and configured by the 337 operator at the ingress/egress PE for asymmetrical traffic. 339 6.4. Data Plane 341 Referring to Figure 4, after checking the presence of the PW Update 342 sub-TLV, the egress PE updates its PW-to-Label bindings with the 343 newly assigned Label L10. This Label is associated to the new format 344 defined by [iP1,iP2new] of the PW packet. The egress PE changes over 345 the traffic received from CE2 to the new format [iP1, iP2new] with 346 the new Label L10 thus deprecating the use of older format [iP1, iP2] 347 with label L2. This new Label assignment allows in-band detection. 348 Indeed, the ingress PE identifies the Label L10 and hence deduces the 349 associated format. This in-band detection is essential to allow it to 350 restitute correctly the traffic over its AC. That is particularly 351 required when the length field of the PW header is not sufficient to 352 correctly forward the traffic to the AC (e.g. CESoPSN PW). 354 The same procedure applies for the reverse direction. 356 Figure 4 corresponds to the "increase PW capacity" case since CE1 and 357 CE2 here send the new payload format F2 once the PW has been updated. 359 Note that the requirement to update the interface parameters without 360 any service disruption implies that each direction of the PW must 361 follow the procedure separately. This means that for some duration of 362 time during the update process, traffic from the egress PE to the 363 ingress PE may be in the new format, while traffic in the reverse 364 direction remains in the previous format. 366 7. Use Case: CESoPSN 368 The need to update interface parameters without service interruption 369 is particularly relevant for CESoPSN PWs. CESoPSN PWs carry TDM 370 traffic in a structure-aware fashion, with explicit specification of 371 the PW capacity (in multiples of 64 kbps). When using CESoPSN PWs, 372 there is an inherent trade-off between bandwidth consumption and 373 latency. It is thus very important to carefully match the capacity to 374 the actual payload. 376 CESoPSN PWs are frequently used to encapsulate traffic in the mobile 377 backhauling architectures. When setting up such backhauling PWs the 378 needed capacity is known, but when growing the network the capacity 379 of particular PWs needs to grow without interrupting ongoing voice 380 services used by numerous customers. 382 7.1. Interface Parameters for CESoPSN PWs 384 This section refers to [PW TDM CTRL]. 386 7.1.1. CEP/TDM Payload Bytes (0x04) 388 The interface parameter CEP/TDM Payload Bytes (0x04) (P) is defined 389 in [PW TDM CTRL] for a set of TDM PW types including SAToP. For 390 CESoPSN PWs, The specified value P MUST be an integer multiple factor 391 of N, where N is the number of timeslots in the attachment circuit. 393 7.1.2. CEP/TDM Bit-Rate (0x07) 395 For all kinds of structure-aware emulation, this parameter MUST be 396 set to N where N is the number of DS0 channels in the corresponding 397 attachment circuit that must be retrieved from the E1 frames and 398 must be transported over the CESoPSN PW. 400 Note that the number of frames to be encapsulated per PW packet is 401 derived from the value (P) and (N). 403 Packetization latency, number of timeslots and payload size are 404 linked by the following obvious relationship: 406 L = 8*N*D 408 where: 409 o D is packetization latency, milliseconds 410 o L is packet payload size, octets 411 o N is number of DS0 channels. 413 The payload corresponding to the value N are selected from the E1 414 frames, so as the CEP/TDM Payload Bytes (P) defined in [PW TDM CTRL] 415 corresponds to the value L multiplied by a number of E1 frames to be 416 encapsulated over the CESoPSN PW. 418 7.2. CESoPSN Interface Parameters Update Mechanism Reference Model 420 +----+ +----+ 421 +-----+ | PE1|==================| PE2| +-----+ 422 | | | | | | | | 423 | CE1 |----------|............PW1.............|----------| CE2 | 424 | | | | | | | | 425 +-----+ | |==================| | +-----+ 426 +----+ +----+ 427 N1-> LLM (FEC1, L1, int. Par. [N1, P1]) <-N1 428 ----------------------> 429 LLM (FEC1, L2, int. Par. [N1, P1]) 430 <----------------------- 432 ==========L2==========> 434 <=========L1=========== 435 . 436 . 437 LLM (FEC1, L10, Update (iP, L), new int. Par. [N2, P2]) 438 -----------------------. 439 <=========L10========== 440 LLM (FEC1, L20, Update (iP, L), new int. Par. [N2, P2]) 441 <----------------------- 442 =========L20=========> 443 N2-> <-N2 445 Figure 5 CESoPSN PW Update Mechanism Reference Model 447 Figure 5 depicts the procedure to update CESoPSN interface 448 parameters. Initially PE1, the ingress PE is assumed to setup a 449 CESoPSN PW with PE2, the egress PE with the two interface parameters 450 (N, P) defined in section 7.1.1, 7.1.2. 452 CE1 and CE2 are sending E1 frames with N1 timeslots payload. 454 The ingress PE picks the N1 timeslots from E1 frames to reach a 455 total payload of (P), encapsulates them in a PW packet and forwards 456 the PW packet to the ingress PE with Label L2. 458 7.3. Control Plane 460 Referring to Figure 5, after the operator configures the new 461 interface parameters (N2, P2), the ingress PE initiates a new LLM 462 message to indicate them to the egress PE. The LLM message includes 463 the PW Update sub-TLV which specifies the parameters to be updated 464 (interface parameter iP, PW Label L). The LLM message contains the 465 new interface paramters'value and the new Label L10. 467 Upon reception of the LLM message the egress PE checks the presence 468 of the PW Update sub-TLV. Since the PW Update sub-TLV is included in 469 the LLM message, the egress PE carries on the process by responding 470 to the ingress PE with a new LMM message as described in [RFC4447] 471 with the new interface parameters and a new Label L20. 473 7.4. Data Plane 475 Referring to Figure 5, after checking the presence of the PW Update 476 sub-TLV, the egress PE updates its PW-to-Label bindings with the new 477 assigned Label L10. This Label is associated to the new format 478 defined by [N, P] of the PW packet. The egress PE switches the 479 traffic received from CE2 from PW1 in the previous format [N1, P1] 480 with the Label L1 to PW1 in the new format [N2, P2] with the new 481 Label L10. This new Label assignment allows in-band detection. Indeed 482 the ingress PE identifies the Label L10 and hence deduces the 483 associated format. This in-band detection is essential to allow it to 484 restitute correctly the traffic over its AC. 486 The same procedure applies for the reverse direction. 488 Figure 5 corresponds to the "increase PW capacity" case since CE1 and 489 CE2 here send the new payload (N2 timeslots payload per E1 frames) 490 once the PW has been updated. 492 Note that the procedure assumes that some empty payload is 493 encapsulated per PW packet between the both steps. 495 8. MS-PW Applicability 497 The PW update mechanism applies in an MS-PW environment as described 498 in [MS-PW ARCH]. 500 The S-PEs must accept the new assigned Label, so must also be 501 capable to interpret the PW Update sub-TLV. The S-PEs must initiate 502 new LLM messages to the next hop with the new interface parameters 503 received from the ingress T-PE. These messages must contain a new PW 504 Label, so must also include the PW Update sub-TLV. 506 This section will be completed with more detail in a future version. 508 9. Pseudowire Update Backward Compatibility 510 TBD: in this draft a new capability bit, following procedures 511 defined in draft-thomas-mpls-ldp-capabilities-01.txt 512 With regards to Figure 4, since the ingress PE initiates the LLM 513 message, it MUST specify the PW Update sub-TLV without any Update 514 Code in the initial message in order to negotiate it with the egress 515 PE. 517 When the egress PE receives the LLM message from the ingress PE, if 518 it supports the PW Update sub-TLV, at turn it MUST include it in the 519 LLM message in response to the initial message. 521 If the egress PE does not support the PW Update sub-TLV, it will 522 silently discard the sub-TLV as the U bit is set and the F bit is 523 cleared and will continue to perform the PW setup by initiating a 524 LLM message to the ingress PE. 526 In that case the egress PE sends a LLM message to the ingress PE 527 without the PW Update sub-TLV. The absence of this sub-TLV informs 528 the ingress PE that the egress PE is not capable to deal with the PW 529 Update sub-TLV. 531 10. Security Considerations 533 This security considerations of RFC4447 apply here as well. 535 11. IANA Considerations 537 Most of the IANA assignments required by this draft are already 538 listed in [RFC4446]. 540 11.1. LDP TLV Type 542 This document uses a new LDP TLV types; IANA already maintains a 543 registry of name "TLV TYPE NAME SPACE" defined by RFC 3036. The 544 following values are suggested for assignment: 546 Sub-TLV PW Update 548 11.2. LDP PW Update Codes 550 This document proposes the definition of two new LDP PW Update codes 551 corresponding to the interface parameters and to the PW label 552 change. 554 The following values are suggested for assignment: 556 Range/Value E Description Reference 557 ------------- ----- ---------------------- --------- 559 12. Acknowledgments 561 This draft borrows from concepts developed by Himanshu Shah in an 562 earlier draft entitled "Dynamic Parameters Signaling for MPLS-based 563 Pseudowires". 565 13. References 567 13.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, March 1997. 572 [RFC4234] Crocker, D. and Overell, P.(Editors), "Augmented BNF 573 for Syntax Specifications: ABNF", Internet Mail 574 Consortium and Demon Internet Ltd., November 1997. 576 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to 577 Edge Emulation (PWE3)", April 2006 579 [RFC4447] El-Aawar, N., Heron, G., Martini, L., Smith, T., Rosen, 580 E., "Pseudowire Setup and Maintenance Using the Label 581 Distribution Protocol (LDP)", April 2006 583 13.2. Informative References 585 [PW TDM CTRL] Stein, Y., Vainshtein, A., "Control Protocol 586 Extensions for Setup of TDM Pseudowires", Internet 587 Draft, draft-ietf-pwe3-tdm-control-extensi-04.txt, 588 March 2008 590 [MS-PW ARCH] Bocci, M., and Bryant, S.,T., "An Architecture for 591 Multi-Segment Pseudo Wire Emulation Edge-to-Edge", 592 Internet Draft, draft-ietf-pwe3-ms-pw-arch-03.txt, 593 October 2006 595 [PWE3 CESoPSN] Vainstein, A, and al., "Structure-aware TDM Circuit 596 Emulation Service over Packet Switched Network 597 (CESoPSN)", Internet Draft, draft-ietf-pwe3-cesopsn- 598 07, LC 600 Author's Addresses 602 Frederic Jounay 603 France Telecom 604 2, avenue Pierre-Marzin 605 22307 Lannion Cedex 606 FRANCE 607 Email: frederic.jounay@orange-ftgroup.com 608 Philippe Niger 609 France Telecom 610 2, avenue Pierre-Marzin 611 22307 Lannion Cedex 612 FRANCE 613 Email: philippe.niger@orange-ftgroup.com 615 Yaakov (Jonathan) Stein 616 RAD Data Communications 617 24 Raoul Wallenberg St., Bldg C 618 Tel Aviv 69719 619 ISRAEL 620 Email: yaakov_s@rad.com 622 Himanshu Shah 623 Ciena Corp 624 35 Nagog Park 625 Acton, MA 01720 626 USA 627 Email: hshah@ciena.com 629 Intellectual Property Statement 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed 633 to pertain to the implementation or use of the technology described 634 in this document or the extent to which any license under such 635 rights might or might not be available; nor does it represent that 636 it has made any independent effort to identify any such rights. 637 Information on the procedures with respect to rights in RFC 638 documents can be found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use 643 of such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository 645 at http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org. 653 Disclaimer of Validity 655 This document and the information contained herein are provided on 656 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 657 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 658 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 659 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 660 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 661 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 662 FOR A PARTICULAR PURPOSE. 664 Copyright Statement 666 Copyright (C) The IETF Trust (2007). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 Acknowledgment 673 Funding for the RFC Editor function is currently provided by the 674 Internet Society.