idnits 2.17.1 draft-martini-pwe3-p2mp-pw-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2009) is 5298 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: 'RFC3472' is mentioned on line 433, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-p2mp-pw-requirements-01 == Outdated reference: A later version (-18) exists of draft-ietf-mpls-p2mp-lsp-ping-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft Maciek Konstantynowicz 4 Intended status: Standards Track Sami Boutros 5 Expires: April 24, 2010 Siva Sivabalan 6 Cisco 8 Frederic Jounay Gianni Del Vecchio 9 Philippe Niger Swisscom 10 France Telecom 12 Simon Delord Lizhong Jin 13 Telstra Nokia Siemens 15 Laurent Ciavaglia 16 Martin Vigoureux 17 Alcatel-Lucent 18 October 24, 2009 20 Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP 22 draft-martini-pwe3-p2mp-pw-01.txt 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 24, 2010 47 Abstract 49 This document specifies a mechanism to signal Point-to-Multipoint 50 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 51 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 52 MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is 53 root initiated. 55 Table of Contents 57 1 Specification of Requirements ........................ 2 58 2 Introduction ......................................... 3 59 3 Terminology .......................................... 4 60 4 Signaling the P2MP PW ................................ 5 61 4.1 PW ingress to egress incompatibility issues .......... 6 62 4.2 P2MP PW FEC Element .................................. 6 63 4.3 Group ID usage ....................................... 9 64 4.4 Generic Label TLV .................................... 9 65 4.5 Transport LSP TLV .................................... 10 66 5 LDP Capability Negotiation ........................... 12 67 6 P2MP PW status ....................................... 13 68 7 Security Considerations .............................. 13 69 8 IANA Considerations .................................. 13 70 8.1 FEC Type Name Space .................................. 13 71 8.2 LDP TLV TYPE ......................................... 14 72 9 References ........................................... 14 73 9.1 Normative References ................................. 14 74 9.2 Informative References ............................... 15 75 10 Author's Addresses ................................... 15 77 1. Specification of Requirements 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Introduction 85 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 86 attributes of a unidirectional P2MP Telecommunications service such 87 as P2MP ATM over PSN. A major difference between a Point-to-Point 88 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 89 intended for bidirectional service whereas the latter is intended for 90 both unidirectional, or optionally bidirectional service. 91 Requirements for P2MP PW are described in [P2MP-PW-REQ]. 93 P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or 94 Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW-REQ]. 95 P2MP MS-PW is outside the scope of this document. A reference model 96 for P2MP PW is depicted in Figure 1 below. A transport LSP associated 97 with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel 98 established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP 99 [mLDP]) spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW 100 tree. For example, in Figure 1, PW1 can be associated with a P2MP TE 101 tunnel or P2MP LSP setup using [mLDP] originating from PE1 and 102 terminating at PE2 and PE3. 104 |<--------------P2MP PW---------------->| 105 Native | | Native 106 Service | |<--PSN1->| |<--PSN2->| | Service 107 (AC) V V V V V V (AC) 108 | +-----+ +------+ +------+ | 109 | | | | P1 |=========|T-PE2 |AC3 | +---+ 110 | | | | .......PW1.........>|-------->|CE3| 111 | |T-PE1|=========| . |=========| | | +---+ 112 | | .......PW1........ | +------+ | 113 | | . |=========| . | +------+ | 114 | | . | | . |=========|T-PE3 |AC4 | +---+ 115 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 116 |CE1|------->|... | | |=========| | | +---+ 117 +---+ | | . | +------+ +------+ | 118 | | . | +------+ +------+ | 119 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 120 | | .......PW1..............PW1.........>|-------->|CE5| 121 | | |=========| |=========| | | +---+ 122 | +-----+ +------+ +------+ | 124 Figure 1: P2MP PW 126 Mechanisms for establishing P2P SS-PW using LDP are described in 127 [RFC4447]. In this document, we specify a method to signal P2MP PW 128 using LDP. In particular, we define new TLVs, parameters, and status 129 codes to facilitate LDP to signal and maintain P2MP PWs. 131 Note that even though the traffic flow from a Root-PE to Leaf-PE(s) 132 is P2MP in nature, it may be desirable for any Leaf-PE to send 133 unidirectional P2P traffic destined only to the Root-PE. The proposed 134 mechanism takes such an option into consideration. 136 The P2MP PW requires an MPLS LSP to carry the PW traffic. the PW MPLS 137 packet will be encapsulated according to the methods described in 138 [RFC5332]. 140 3. Terminology 142 FEC: Forwarding Equivance Class 144 LDP: Label Distribution Protocol 146 mLDP: Label Distribution Protocol for P2MP LSP 148 LSP: Label Switching Path 150 MS-PW: Multi-Segment Pseudowire 152 P2P: Point to Point 154 P2MP: Point to Multipoint 156 PE: Provider Edge 158 PSN: Packet Switched Network 160 PW: Pseudowire 162 SS-PW: Single-Segment Pseudowire 164 S-PE: Switching Provider Edge Node of MS-PW 166 TE: Traffic Engineering 168 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 170 L-PE: Leaf-PE - egress PE. 172 4. Signaling the P2MP PW 174 In order to advertise labels as well as exchange PW related LDP 175 messages, PEs must establish LDP sessions among themselves using the 176 Extended Discovery Mechanisms. A PE discovers other PEs that are to 177 be connected via P2MP PWs either via manual configuration or 178 autodiscovery [BGP-AD]. 180 Root-PE and each Leaf-PE MUST be configured with the same FEC as 181 defined in the following section. 183 P2MP PW requires that there is an active P2MP PSN LSP set up between 184 Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP 185 PSN LSP is different depending on the protocol used: RSVP-TE or mLDP. 187 In case of mLDP a Leaf-PE can decide to join the P2MP LSP at any 188 time, while in case of RSVP-TE the P2MP LSP is set up by the Root-PE, 189 generally at the initial service provisioning time. It should be 190 noted that local policy can override any decision to join, add or 191 prune existing or new Leaf-PE(s) from the tree. 193 In any case the PW setup can ignore these differences, and simply 194 assume that the P2MP tunnel is available when needed. 196 The P2MP PW is initiated by the root (source) Provider Edge router 197 (R-PE), by simply sending an P2MP-PW LDP label mapping message to all 198 the Leaf Provider Edge routers L-PEs. This label mapping message will 199 contain the following: 200 -i. P2MP PW FEC element. 201 -ii. an Interface Parameters TLV, as described in [RFC4447] sec 202 5.3.2.1 203 -iii. a PW Grouping TLV, as described in [RFC4447] sec 5.3.2.2 204 -iv. a Transport LSP TLV. 205 -v. a label TLV for the upstream-assigned label R-PE to L-PE 206 direction. 207 -vi. MAY contain a downstream-assigned label for the L-PE to R-PE 208 direction. 210 The LDP liberal label retention mode is used, and per [RFC5036] 211 requirement the label request message MUST also be supported. 213 The Upstream-assigned label is allocated according to the rules in 214 [RFC5331]. 216 When a Leaf-PE receives a PW Label Mapping Message, it MUST verify 217 the associated P2MP transport LSP is in place. 219 If the associated transport P2MP LSP is not in place, and the 220 transport LSP TLV type is LDP P2MP LSP, a Leaf-PE SHOULD attempt to 221 join the P2MP transport associated with the P2MP PW. 223 If the associated transport P2MP LSP is not in place, and the 224 transport LSP TLV type is RSVP-TE P2MP LSP, a Leaf-PE SHOULD await 225 RSVP-TE P2MP LSP signaling from the Root-PE. 227 4.1. PW ingress to egress incompatibility issues 229 If a Root-PE signals a PW with a pw type, CW mode, or interface 230 parameters that a particular Leaf-PE cannot accept, then the L-PE 231 must simply not enable the PW, and notify the user. In this case a PW 232 status message of 0x00000001 - Pseudowire Not Forwarding MUST also be 233 sent to the R-PE. 235 Note that this procedure does not apply if the L-PE had not been 236 provisioned with this particular P2MP PW. In this case according to 237 the LDP liberal label retention rules, no action is taken. 239 4.2. P2MP PW FEC Element 241 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 242 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 243 We define a new type of FEC element called "P2MP PW FEC Element" 244 whose type is 0x82 (Pending IANA Allocation) and is encoded as 245 follows: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |FEC Type = 0x82|C| PW Type | PW Info Length| 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | AGI Type | Length | AGI Value | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ~ AGI Value (contd.) ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | AII Type | Length | SAII Value | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 ~ SAII Value (contd.) ~ 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |0|0| Transport LSP TLV (0x0971)| Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved |PMSI Tunnel Typ| Transport LSP ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 ~ Transport LSP ID (contd.) ~ 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 | Optional Parameters | 271 ~ ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 2: P2MP PW FEC Element 276 * PW Type: 278 15-bit representation of PW type, and the assigned values are 279 assigned by IANA. 281 * C bit: 283 A value of 1 or 0 indicates whether control word is present or 284 absent for the P2MP PW. 286 * PW Info Length: 288 Sum of the lengths of AGI, SAII and Optional Parameters field in 289 octets. If this value is 0, then it references all PWs using the 290 specified grouping ID. In this case, there are no other FEC 291 element fields (AGI, SAII, etc.) present, nor any interface 292 parameters TLVs. 294 * AGI: 296 Attachment Group Identifier can be used to uniquely identify VPN 297 or VPLS instance associated with the P2MP PW. This has the same 298 format as that of the Generalized PWid FEC element [RFC4447]. 300 * SAII: 302 Source Attachment Individual Identifier is used to identify the 303 root of the P2MP PW. The root is represented using AII type 2 304 format specified in [RFC5003]. Note that the SAII can be omitted 305 by simply setting the length and type to zero. 307 P2MP PW is identified by the Source Attachment Identifier (SAI). 308 If the AGI is non-null, the SAI is the combination of the SAII 309 and the AGI, if the AGI is null, the SAI is the SAII. 311 * Transport LSP TLV: 313 A P2MP PW MUST be associated with a transport LSP. The Transport 314 LSP TLV contains the information required to identify the 315 transport LSP. Note that the Transport LSP TLV MUST immediately 316 follow the FEC , but is not part of the FEC, and SHOULD NOT be 317 used in other messages where the FEC is used. 319 * Optional Parameters: 321 The Optional Parameter field can contain some TLVs that are not 322 part of the FEC, but are necessary for the operation of the PW. 323 This document defines two such parameters: Interface Parameters 324 TLV, and Group ID TLV. 326 The Interface Parameters TLV and Group ID TLV specified in [RFC4447] 327 can also be used in conjunction with P2MP PW FEC. For Group ID TLV 328 the sender and receiver of these TLVs should follow the same rules 329 and procedures specified in [RFC4447]. For Interface Parameters TLV 330 the procedure differs from the one specified in [RFC4447] due to 331 specifics of P2MP connectivity. When the interface parameters are 332 signaled by the Root-PE, the Leaf-PE must check if its configured 333 value(s) is less than or equal to the threshold value provided by the 334 Root-PE (e.g. MTU size (Ethernet), max number of concatenated ATM 335 cells, etc)). For other interface parameters like CEP/TDM Payload 336 bytes (TDM), the value MUST match exactly the the one signaled by the 337 Root-PE. 339 Note that since the LDP label mapping message is only sent by the R- 340 PE to all the L-PEs it is not possible to negotiate any interface 341 parameters. 343 4.3. Group ID usage 345 The Grouping TLV as defined in [RFC4447] contains a group ID capable 346 of indicating an arbitrary group membership of a P2MP-PW. This group 347 ID can be used in LDP "wild card" status, and withdraw label 348 messages, as described in [RFC4447]. 350 4.4. Generic Label TLV 352 For a given P2MP PW, a single upstream-assigned label is allocated by 353 the Root-PE, and is advertised to all Leaf-PEs using the Generic 354 Label TLV in the label mapping message containing the P2MP PW FEC 355 element. The Root-PE imposes the upstream-assigned label on the 356 outbound packets sent over the P2MP-PW, and using this label a Leaf- 357 PE identifies the inbound packets arriving over the P2MP PW. Even 358 though the P2MP PW is unidirectional, it may be possible for a Root- 359 PE to receive traffic from any Leaf-PE using a unidirectional P2P PW 360 in the reverse direction as outlined in [P2MP-PW-REQ]. For this 361 purpose, the Root-PE can also allocate a unique downstream-assigned 362 label for each Leaf-PE from which it is intended to receive P2P 363 traffic. In other words, Label Mapping Message for a P2MP PW from a 364 Root-PE to a Leaf-PE MUST carry a upstream-assigned label and MAY 365 carry an OPTIONAL downstream-assigned label. 367 As in the case of P2P PW signaling, P2MP PW labels are carried within 368 Generic Label TLV contained in LDP Label Mapping Message. A Generic 369 Label TLV is formatted and processed as per the rules and procedures 370 specified in [RFC4447]. But, as mentioned above, a Label Mapping 371 Message for a P2MP PW can have up to two Generic Label TLVs; one for 372 upstream-assigned label (always) and another for downstream-assigned 373 label (optional). In the case of two Generic Label TLVs, the first 374 TLV (from the beginning of the message) carries upstream-assigned 375 label and the next generic label TLV carries the downstream-assigned 376 label as shown below: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |0|0| Generic Label (0x0200) | Length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Upstream-assigned P2MP Label (mandatory) | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |0|0| Generic Label (0x0200) | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Downstream-assigned P2P Label (optional) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 3: Generic Label TLVs in P2MP PW Label Mapping Message 392 Note that other type of TLVs may appear between the above generic 393 label TLVs, however any other generic label TLV MUST NOT appear 394 between the upstream-assigned P2MP Label TLV, and downstream-assigned 395 P2P Label TLV. 397 4.5. Transport LSP TLV 399 A P2MP PW MUST be associated with a transport LSP which can be 400 established using RSVP-TE or mLDP. Thus, a Label Mapping Message MUST 401 contain the identity of the transport LSP. For this purpose, this 402 specification introduces a new TLV called "Transport LSP TLV" which 403 has the following format: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |0|0| Transport LSP TLV (0x0971)| Length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Reserved |PMSI Tunnel Typ| Tunnel Identifier | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 ~ Tunnel Identifier (contd.) ~ 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 4: Transport LSP TLV 418 Note: TLV number pending IANA allocation. 420 * Reserved Flags: 422 Reserved bits Must be set to 0 when transmitting the message, and 423 ignored on receiving the message. 425 * PMSI Tunnel Type: 427 The Transport LSP Type identifies the type of technology used to 428 establish a transport LSP. The PMSI tunnel type is defined in 429 [L3VPN-MCAST]. 431 Editor Comment: This is not finalized yet, as the authors are 432 considering using The CR-LDP construct used in Interface ID TLV 433 in [RFC3472] . 435 * Tunnel Identifier: 437 The Tunnel containing the Transport LSP is identified by the 438 Tunnel Identifier which is defined in [L3VPN-MCAST]. 440 Transport LSP TLV MUST be present only in the Label Mapping Message. 441 An Root-PE sends Label Mapping Message as soon as the transport LSP 442 ID associated with the P2MP PW is known (e.g., via configuration) 443 regardless of the operational state of the transport LSP. Similarly, 444 a Root-PE does not withdraw the labels when the corresponding 445 transport LSP goes down. Furthermore, a Leaf-PE retains the P2MP PW 446 labels regardless of the operational status of the transport LSP. 448 Note that a given transport LSP can be associated with more than one 449 P2MP PW and all P2MP PWs will be sharing the same Root-PE and Leaf- 450 PE(s). 452 In the case of LDP P2MP LSP, when a Leaf-PE receives the Label 453 Mapping Message, it can initiate the process of joining the P2MP LSP 454 tree associated with the P2MP PW. 456 In the case of RSVP-TE P2MP LSP, only the Root-PE initiates the 457 signaling of P2MP LSP. 459 5. LDP Capability Negotiation 461 The capability of supporting P2MP PW must be advertised to all LDP 462 peers. This is achieved by using the methods in [RFC5561] and 463 advertising the P2MP PW LDP capability TLV. If an LDP peer supports 464 the dynamic capability advertisement, this can be done by sending a 465 new capability message with the S bit set for the P2MP PW capability 466 TLV. If the peer does not support dynamic capability advertisement, 467 then the P2MP PW TLV MUST be included in the LDP initialization 468 procedures in the capability parameter [RFC5561]. 470 In line with requirements listed in [RFC5561] the following TLV is 471 defined to indicate the P2MP PW capability: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |U|F| TLV Code Point=0x703 | Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 |S| Reserved | Reserved | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 5: P2MP PW LDP Capability TLV 483 Note: TLV number pending IANA allocation. 485 * U-bit: 487 SHOULD be 1 (ignore if not understood). 489 * F-bit: 491 SHOULD be 0 (don't forward if not understood). 493 * TLV Code Point: 495 The TLV type, which identifies a specific capability. The P2MP PW 496 capability code point is requested in the IANA allocation section 497 below. 499 * S-bit: 501 The State Bit indicates whether the sender is advertising or 502 withdrawing the P2MP PW capability. The State bit is used as 503 follows: 504 1 - The TLV is advertising the capability specified by the 505 TLV Code Point. 507 0 - The TLV is withdrawing the capability specified by the 508 TLV Code Point. 510 6. P2MP PW status 512 In order to support the proposed mechanism, a node MUST be capable of 513 handling PW status. As such, PW status negotiation procedure 514 described in [RFC4447] is not applicable to P2MP PW. 516 Once a Leaf-PE successfully process a Label Mapping Message for a 517 P2MP PW, it MUST send appropriate PW status according to the 518 procedure specified [RFC4447] to notify the PW status. If there is no 519 PW status notification required, then no PW status notification is 520 sent. (for example if the P2MP PW is established and operational with 521 a status 0f 0x00000000 no pw status message is necessary). 523 PW status message sent from any Leaf-PE to Root-PE contains P2MP PW 524 FEC to identify the PW. Finally, a Root-PE also sends PW status to 525 Leaf-PE(s) to reflect its view of a P2MP PW state. 527 Connectivity status of the underlying P2MP LSP that P2MP PW is 528 associated with, can be verified using LSP Ping and Traceroute 529 procedures described in [P2MP-LSP-PING]. 531 7. Security Considerations 533 The security measures described in [RFC4447] is adequate for the 534 proposed mechanism. 536 8. IANA Considerations 538 8.1. FEC Type Name Space 540 This document uses a new FEC element types, number 0x82 will be 541 requested as an allocation from the registry "FEC Type Name Space" 542 for the Label Distribution Protocol (LDP RFC5036): 544 Value Hex Name Reference 545 ------- ----- ----------------------------- --------- 546 130 0x82 P2MP PW FEC Element RFCxxxx 548 8.2. LDP TLV TYPE 550 This document uses a new LDP TLV types, IANA already maintains a 551 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 552 following values are suggested for assignment: 554 TLV type Description 555 0x0971 Transport LSP TLV 556 0x0703 P2MP PW Capability TLV 558 9. References 560 9.1. Normative References 562 [RFC2119] Bradner. S, "Key words for use in RFCs to 563 Indicate Requirement Levels", RFC 2119, March, 1997. 565 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 566 et al., rfc4447 April 2006. 568 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 569 Specification", RFC 5036, October 2007. 571 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 572 Individual Identifier (AII) Types for Aggregation", RFC5003, 573 September 2007. 575 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 576 Assignment and Context-Specific Label Space", rfc5331, 577 August 2008. 579 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, 580 "MPLS Multicast Encapsulations", rfc5332, August 2008. 582 [mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 583 Distribution Protocol Extensions for Point-to-Multipoint and 584 Multipoint-to-Multipoint Label Switched Paths", 585 draft-ietf-mpls-ldp-p2mp-06, Work In Progress, April 2009. 587 [RFC4875] 588 R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 589 "Extensions to Resource Reservation Protocol - Traffic 590 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 591 Switched Paths (LSPs).", rfc4875, May 2007. 593 [L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, 594 "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 595 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, 596 Work in Progress, October 2009. 598 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, 599 "LDP Capabilities", rfc5561, July 2009. 601 9.2. Informative References 603 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", 604 RFC3985 606 [BGP-AD] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, 607 Autodiscovery, and Signaling in L2VPNs", 608 draft-ietf-l2vpn-signaling-08.txt May 2006. 610 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point 611 to Multipoint Pseudowire", 612 draft-ietf-pwe3-p2mp-pw-requirements-01.txt, Work in Progress, 613 July 2009. 615 [P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane 616 Failures in Point-to-Multipoint Multiprotocol Label Switching 617 (MPLS) - Extensions to LSP Ping", 618 draft-ietf-mpls-p2mp-lsp-ping-08.txt, Work In Progress, 619 August 2009. 621 10. Author's Addresses 623 Luca Martini 624 Cisco Systems, Inc. 625 9155 East Nichols Avenue, Suite 400 626 Englewood, CO, 80112 627 e-mail: lmartini@cisco.com 629 Sami Boutros 630 Cisco Systems, Inc. 631 170 West Tasman Drive 632 San Jose, CA 95134 633 e-mail: sboutros@cisco.com 634 Siva Sivabalan 635 2000 Innovation Drive 636 Kanata, ONTARIO K2K 3E8 637 CANADA 638 e-mail: msiva@cisco.com 640 Maciek Konstantynowicz 641 10 New Square Park 642 Bedfont Lakes 643 Feltham, England TW14 8HA 644 UNITED KINGDOM 645 e-mail: mkonstan@cisco.com 647 Gianni Del Vecchio 648 Swisscom (Schweiz) AG 649 Zentweg 9 650 CH-3006 Bern 651 Switzerland 652 e-mail: Gianni.DelVecchio@swisscom.com 654 Thomas D. Nadeau 655 BT 656 BT Centre 657 81 Newgate Street 658 London EC1A 7AJ 659 United Kingdom 660 e-mail: tom.nadeau@bt.com 662 Frederic Jounay 663 France Telecom 664 2, avenue Pierre-Marzin 665 22307 Lannion Cedex 666 FRANCE 667 Email: frederic.jounay@orange-ftgroup.com 669 Philippe Niger 670 France Telecom 671 2, avenue Pierre-Marzin 672 22307 Lannion Cedex 673 FRANCE 674 Email: philippe.niger@orange-ftgroup.com 675 Yuji Kamite 676 NTT Communications Corporation 677 Tokyo Opera City Tower 678 3-20-2 Nishi Shinjuku, Shinjuku-ku 679 Tokyo 163-1421 680 Japan 681 Email: y.kamite@ntt.com 683 Lizhong Jin 684 Nokia Siemens Networks 685 Building 89, 1122 North QinZhou Road, 686 Shanghai, 200233 687 P.R.China 688 Email: lizhong.jin@nsn.com 690 Martin Vigoureux 691 Alcatel-Lucent 692 Route de Villejust 693 Nozay, 91620 694 France 695 Email: martin.vigoureux@alcatel-lucent.com 697 Laurent Ciavaglia 698 Alcatel-Lucent 699 Route de Villejust 700 Nozay, 91620 701 France 702 Email: Laurent.Ciavaglia@alcatel-lucent.com 704 Simon Delord 705 Telstra 706 242 Exhibition Street 707 Melbourne, VIC, 3000, Australia 708 E-mail: simon.a.delord@team.telstra.com 710 Full Copyright Statement 712 Copyright (c) 2009 IETF Trust and the persons identified as the 713 document authors. All rights reserved. 715 This document is subject to BCP 78 and the IETF Trust's Legal 716 Provisions Relating to IETF Documents in effect on the date of 717 publication of this document (http://trustee.ietf.org/license-info). 718 Please review these documents carefully, as they describe your rights 719 and restrictions with respect to this document. 721 Acknowledgments 723 The authors wish to acknowledge the contributions of Ali Sajassi. 725 Expiration Date: April 2010