idnits 2.17.00 (12 Aug 2021) /tmp/idnits38770/draft-ietf-pwe3-p2mp-pw-02.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 : ---------------------------------------------------------------------------- == 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2011) is 4097 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 4447 (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-l3vpn-2547bis-mcast-bgp has been published as RFC 6514 == Outdated reference: draft-ietf-pwe3-p2mp-pw-requirements has been published as RFC 7338 == Outdated reference: draft-ietf-mpls-p2mp-lsp-ping has been published as RFC 6425 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Sami Boutros 3 Internet Draft Luca Martini 4 Expiration Date: September 2011 Siva Sivabalan 5 Intended status: Standards Track Cisco 7 Maciek Konstantynowicz 8 Juniper 10 Frederic Jounay Gianni Del Vecchio 11 Philippe Niger Swisscom 12 France Telecom 14 Thomas D. Nadeau Yuji Kamite 15 Huawei NTT Communications 17 Simon Delord Lizhong Jin 18 Telstra ZTE 20 Laurent Ciavaglia 21 Martin Vigoureux 22 Alcatel-Lucent 23 March 2, 2011 25 Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP 27 draft-ietf-pwe3-p2mp-pw-02.txt 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 2, 2010 52 Abstract 54 This document specifies a mechanism to signal Point-to-Multipoint 55 (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable 56 for any Layer 2 VPN service requiring P2MP connectivity over an IP or 57 MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is 58 root initiated. 60 Table of Contents 62 1 Specification of Requirements ........................ 3 63 2 Introduction ......................................... 3 64 3 Terminology .......................................... 4 65 4 Signaling the P2MP PW ................................ 5 66 4.1 PW ingress to egress incompatibility issues .......... 6 67 4.2 P2MP PW FEC Element .................................. 7 68 4.3 Group ID usage ....................................... 9 69 4.4 Generic Label TLV .................................... 9 70 4.5 Transport LSP TLV .................................... 10 71 5 LDP Capability Negotiation ........................... 12 72 6 P2MP PW status ....................................... 13 73 7 Security Considerations .............................. 13 74 8 IANA Considerations .................................. 13 75 8.1 FEC Type Name Space .................................. 13 76 8.2 LDP TLV TYPE ......................................... 14 77 8.3 mLDP Opaque Value Element TLV TYPE ................... 14 78 9 References ........................................... 14 79 9.1 Normative References ................................. 14 80 9.2 Informative References ............................... 15 81 10 Author's Addresses ................................... 16 83 1. Specification of Requirements 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 92 attributes of a unidirectional P2MP Telecommunications service such 93 as P2MP ATM over PSN. A major difference between a Point-to-Point 94 (P2P) PW outlined in [RFC3985] and a P2MP PW is that the former is 95 intended for bidirectional service whereas the latter is intended for 96 both unidirectional, or optionally bidirectional service. 97 Requirements for P2MP PW are described in [P2MP-PW-REQ]. 99 P2MP PW can be constructed as either Single Segment (P2MP SS-PW) or 100 Multi Segment (P2MP MS-PW) Pseudowires as mentioned in [P2MP-PW-REQ]. 101 P2MP MS-PW is outside the scope of this document. A reference model 102 for P2MP PW is depicted in Figure 1 below. A transport LSP associated 103 with a P2MP SS-PW SHOULD be a P2MP MPLS LSP (i.e., P2MP TE tunnel 104 established via RSVP-TE [RFC4875] or P2MP LSP established via mLDP 105 [mLDP]) spanning from the Root-PE to the Leaf-PE(s) of the P2MP SS-PW 106 tree. For example, in Figure 1, PW1 can be associated with a P2MP TE 107 tunnel or P2MP LSP setup using [mLDP] originating from PE1 and 108 terminating at PE2 and PE3. 110 |<--------------P2MP PW---------------->| 111 Native | | Native 112 Service | |<--PSN1->| |<--PSN2->| | Service 113 (AC) V V V V V V (AC) 114 | +-----+ +------+ +------+ | 115 | | | | P1 |=========|T-PE2 |AC3 | +---+ 116 | | | | .......PW1.........>|-------->|CE3| 117 | |T-PE1|=========| . |=========| | | +---+ 118 | | .......PW1........ | +------+ | 119 | | . |=========| . | +------+ | 120 | | . | | . |=========|T-PE3 |AC4 | +---+ 121 +---+ |AC1 | . | | .......PW1.........>|-------->|CE4| 122 |CE1|------->|... | | |=========| | | +---+ 123 +---+ | | . | +------+ +------+ | 124 | | . | +------+ +------+ | 125 | | . |=========| P2 |=========|T-PE4 |AC5 | +---+ 126 | | .......PW1..............PW1.........>|-------->|CE5| 127 | | |=========| |=========| | | +---+ 128 | +-----+ +------+ +------+ | 130 Figure 1: P2MP PW 132 Mechanisms for establishing P2P SS-PW using LDP are described in 133 [RFC4447]. In this document, we specify a method to signal P2MP PW 134 using LDP. In particular, we define new TLVs, parameters, and status 135 codes to facilitate LDP to signal and maintain P2MP PWs. 137 Note that even though the traffic flow from a Root-PE to Leaf-PE(s) 138 is P2MP in nature, it may be desirable for any Leaf-PE to send 139 unidirectional P2P traffic destined only to the Root-PE. The proposed 140 mechanism takes such an option into consideration. 142 The P2MP PW requires an MPLS LSP to carry the PW traffic. the PW MPLS 143 packet will be encapsulated according to the methods described in 144 [RFC5332]. 146 3. Terminology 148 FEC: Forwarding Equivance Class 150 LDP: Label Distribution Protocol 152 mLDP: Label Distribution Protocol for P2MP LSP 154 LSP: Label Switching Path 155 MS-PW: Multi-Segment Pseudowire 157 P2P: Point to Point 159 P2MP: Point to Multipoint 161 PE: Provider Edge 163 PSN: Packet Switched Network 165 PW: Pseudowire 167 SS-PW: Single-Segment Pseudowire 169 S-PE: Switching Provider Edge Node of MS-PW 171 TE: Traffic Engineering 173 R-PE: Root-PE - ingress PE, PE initiating P2MP PW setup. 175 L-PE: Leaf-PE - egress PE. 177 4. Signaling the P2MP PW 179 In order to advertise labels as well as exchange PW related LDP 180 messages, PEs must establish LDP sessions among themselves using the 181 Extended Discovery Mechanisms. A PE discovers other PEs that are to 182 be connected via P2MP PWs either via manual configuration or 183 autodiscovery [RFC6074]. 185 Root-PE and each Leaf-PE MUST be configured with the same FEC as 186 defined in the following section. 188 P2MP PW requires that there is an active P2MP PSN LSP set up between 189 Root-PE and Leaf-PE(s). Note that the procedure to set up the P2MP 190 PSN LSP is different depending on the protocol used: RSVP-TE or mLDP. 192 In case of mLDP a Leaf-PE can decide to join the P2MP LSP at any 193 time, while in case of RSVP-TE the P2MP LSP is set up by the Root-PE, 194 generally at the initial service provisioning time. It should be 195 noted that local policy can override any decision to join, add or 196 prune existing or new Leaf-PE(s) from the tree. 198 In any case the PW setup can ignore these differences, and simply 199 assume that the P2MP tunnel is available when needed. 201 The P2MP PW is initiated by the root (source) Provider Edge router 202 (R-PE), by simply sending an P2MP-PW LDP label mapping message to all 203 the Leaf Provider Edge routers L-PEs. This label mapping message will 204 contain the following: 205 -i. P2MP PW FEC element. 206 -ii. an Interface Parameters TLV, as described in [RFC4447] sec 207 5.3.2.1 208 -iii. a PW Grouping TLV, as described in [RFC4447] sec 5.3.2.2 209 -iv. a Transport LSP TLV. 210 -v. a label TLV for the upstream-assigned label R-PE to L-PE 211 direction. 212 -vi. MAY contain a downstream-assigned label for the L-PE to R-PE 213 direction. 215 The LDP liberal label retention mode is used, and per [RFC5036] 216 requirement the label request message MUST also be supported. 218 The Upstream-assigned label is allocated according to the rules in 219 [RFC5331]. 221 When a Leaf-PE receives a PW Label Mapping Message, it MUST verify 222 the associated P2MP transport LSP is in place. 224 If the associated transport P2MP LSP is not in place, and the 225 transport LSP TLV type is LDP P2MP LSP, a Leaf-PE SHOULD attempt to 226 join the P2MP transport associated with the P2MP PW. 228 If the associated transport P2MP LSP is not in place, and the 229 transport LSP TLV type is RSVP-TE P2MP LSP, a Leaf-PE SHOULD await 230 RSVP-TE P2MP LSP signaling from the Root-PE. 232 4.1. PW ingress to egress incompatibility issues 234 If a Root-PE signals a PW with a pw type, CW mode, or interface 235 parameters that a particular Leaf-PE cannot accept, then the L-PE 236 must simply not enable the PW, and notify the user. In this case a PW 237 status message of 0x00000001 - Pseudowire Not Forwarding MUST also be 238 sent to the R-PE. 240 Note that this procedure does not apply if the L-PE had not been 241 provisioned with this particular P2MP PW. In this case according to 242 the LDP liberal label retention rules, no action is taken. 244 4.2. P2MP PW FEC Element 246 [RFC4447] specifies two types of LDP FEC elements called "PWid FEC 247 Element" and "Generalized PWid FEC Element" used to signal P2P PWs. 248 We define a new type of FEC element called "P2MP PW FEC Element" 249 whose type is 0x82 (Pending IANA Allocation) and is encoded as 250 follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |FEC Type = 0x82|C| PW Type | PW Info Length| 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | AGI Type | Length | AGI Value | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 ~ AGI Value (contd.) ~ 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | AII Type | Length | SAII Value | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 ~ SAII Value (contd.) ~ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |0|0| Transport LSP TLV (0x0971)| Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Reserved |PMSI Tunnel Typ| Transport LSP ID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 ~ Transport LSP ID (contd.) ~ 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 | Optional Parameters | 276 ~ ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 2: P2MP PW FEC Element 281 * PW Type: 283 15-bit representation of PW type, and the assigned values are 284 assigned by IANA. 286 * C bit: 288 A value of 1 or 0 indicates whether control word is present or 289 absent for the P2MP PW. 291 * PW Info Length: 293 Sum of the lengths of AGI, SAII and Optional Parameters field in 294 octets. If this value is 0, then it references all PWs using the 295 specified grouping ID. In this case, there are no other FEC 296 element fields (AGI, SAII, etc.) present, nor any interface 297 parameters TLVs. 299 * AGI: 301 Attachment Group Identifier can be used to uniquely identify VPN 302 or VPLS instance associated with the P2MP PW. This has the same 303 format as that of the Generalized PWid FEC element [RFC4447]. 305 * SAII: 307 Source Attachment Individual Identifier is used to identify the 308 root of the P2MP PW. The root is represented using AII type 2 309 format specified in [RFC5003]. Note that the SAII can be omitted 310 by simply setting the length and type to zero. 312 P2MP PW is identified by the Source Attachment Identifier (SAI). 313 If the AGI is non-null, the SAI is the combination of the SAII 314 and the AGI, if the AGI is null, the SAI is the SAII. 316 * Transport LSP TLV: 318 A P2MP PW MUST be associated with a transport LSP. The Transport 319 LSP TLV contains the information required to identify the 320 transport LSP. Note that the Transport LSP TLV MUST immediately 321 follow the FEC , but is not part of the FEC, and SHOULD NOT be 322 used in other messages where the FEC is used. 324 * Optional Parameters: 326 The Optional Parameter field can contain some TLVs that are not 327 part of the FEC, but are necessary for the operation of the PW. 328 This document defines two such parameters: Interface Parameters 329 TLV, and Group ID TLV. 331 The Interface Parameters TLV and Group ID TLV specified in [RFC4447] 332 can also be used in conjunction with P2MP PW FEC. For Group ID TLV 333 the sender and receiver of these TLVs should follow the same rules 334 and procedures specified in [RFC4447]. For Interface Parameters TLV 335 the procedure differs from the one specified in [RFC4447] due to 336 specifics of P2MP connectivity. When the interface parameters are 337 signaled by the Root-PE, the Leaf-PE must check if its configured 338 value(s) is less than or equal to the threshold value provided by the 339 Root-PE (e.g. MTU size (Ethernet), max number of concatenated ATM 340 cells, etc)). For other interface parameters like CEP/TDM Payload 341 bytes (TDM), the value MUST match exactly the the one signaled by the 342 Root-PE. 344 Note that since the LDP label mapping message is only sent by the R- 345 PE to all the L-PEs it is not possible to negotiate any interface 346 parameters. 348 4.3. Group ID usage 350 The Grouping TLV as defined in [RFC4447] contains a group ID capable 351 of indicating an arbitrary group membership of a P2MP-PW. This group 352 ID can be used in LDP "wild card" status, and withdraw label 353 messages, as described in [RFC4447]. 355 4.4. Generic Label TLV 357 For a given P2MP PW, a single upstream-assigned label is allocated by 358 the Root-PE, and is advertised to all Leaf-PEs using the Generic 359 Label TLV in the label mapping message containing the P2MP PW FEC 360 element. The Root-PE imposes the upstream-assigned label on the 361 outbound packets sent over the P2MP-PW, and using this label a Leaf- 362 PE identifies the inbound packets arriving over the P2MP PW. Even 363 though the P2MP PW is unidirectional, it may be possible for a Root- 364 PE to receive traffic from any Leaf-PE using a unidirectional P2P PW 365 in the reverse direction as outlined in [P2MP-PW-REQ]. For this 366 purpose, the Root-PE can also allocate a unique downstream-assigned 367 label for each Leaf-PE from which it is intended to receive P2P 368 traffic. In other words, Label Mapping Message for a P2MP PW from a 369 Root-PE to a Leaf-PE MUST carry a upstream-assigned label and MAY 370 carry an OPTIONAL downstream-assigned label. 372 As in the case of P2P PW signaling, P2MP PW labels are carried within 373 Generic Label TLV contained in LDP Label Mapping Message. A Generic 374 Label TLV is formatted and processed as per the rules and procedures 375 specified in [RFC4447]. But, as mentioned above, a Label Mapping 376 Message for a P2MP PW can have up to two Generic Label TLVs; one for 377 upstream-assigned label (always) and another for downstream-assigned 378 label (optional). In the case of two Generic Label TLVs, the first 379 TLV (from the beginning of the message) carries upstream-assigned 380 label and the next generic label TLV carries the downstream-assigned 381 label as shown below: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |0|0| Generic Label (0x0200) | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Upstream-assigned P2MP Label (mandatory) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |0|0| Generic Label (0x0200) | Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Downstream-assigned P2P Label (optional) | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 3: Generic Label TLVs in P2MP PW Label Mapping Message 397 Note that other type of TLVs may appear between the above generic 398 label TLVs, however any other generic label TLV MUST NOT appear 399 between the upstream-assigned P2MP Label TLV, and downstream-assigned 400 P2P Label TLV. 402 4.5. Transport LSP TLV 404 A P2MP PW MUST be associated with a transport LSP which can be 405 established using RSVP-TE or mLDP. Thus, a Label Mapping Message MUST 406 contain the identity of the transport LSP. For this purpose, this 407 specification introduces a new TLV called "Transport LSP TLV" which 408 has the following format: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |0|0| Transport LSP TLV (0x0971)| Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Reserved |PMSI Tunnel Typ| Tunnel Identifier | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 ~ Tunnel Identifier (contd.) ~ 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Figure 4: Transport LSP TLV 423 Note: TLV number pending IANA allocation. 425 * Reserved Flags: 427 Reserved bits Must be set to 0 when transmitting the message, and 428 ignored on receiving the message. 430 * PMSI Tunnel Type: 432 The Transport LSP Type identifies the type of technology used to 433 establish a transport LSP. The PMSI tunnel type is defined in 434 [L3VPN-MCAST]. 436 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 437 P2MP FEC Element as defined in [mLDP]. A new mLDP Opaque Value 438 Element type for L2VPN-MCAST application needs to be allocated. 440 Editor Comment: The content of the Opaque Value Element TLV is a 441 TBD. 443 * Tunnel Identifier: 445 The Tunnel containing the Transport LSP is identified by the 446 Tunnel Identifier which is defined in [L3VPN-MCAST]. 448 Transport LSP TLV MUST be present only in the Label Mapping Message. 449 An Root-PE sends Label Mapping Message as soon as the transport LSP 450 ID associated with the P2MP PW is known (e.g., via configuration) 451 regardless of the operational state of the transport LSP. Similarly, 452 a Root-PE does not withdraw the labels when the corresponding 453 transport LSP goes down. Furthermore, a Leaf-PE retains the P2MP PW 454 labels regardless of the operational status of the transport LSP. 456 Note that a given transport LSP can be associated with more than one 457 P2MP PW and all P2MP PWs will be sharing the same Root-PE and Leaf- 458 PE(s). 460 In the case of LDP P2MP LSP, when a Leaf-PE receives the Label 461 Mapping Message, it can initiate the process of joining the P2MP LSP 462 tree associated with the P2MP PW. 464 In the case of RSVP-TE P2MP LSP, only the Root-PE initiates the 465 signaling of P2MP LSP. 467 5. LDP Capability Negotiation 469 The capability of supporting P2MP PW must be advertised to all LDP 470 peers. This is achieved by using the methods in [RFC5561] and 471 advertising the P2MP PW LDP capability TLV. If an LDP peer supports 472 the dynamic capability advertisement, this can be done by sending a 473 new capability message with the S bit set for the P2MP PW capability 474 TLV. If the peer does not support dynamic capability advertisement, 475 then the P2MP PW TLV MUST be included in the LDP initialization 476 procedures in the capability parameter [RFC5561]. 478 In line with requirements listed in [RFC5561] the following TLV is 479 defined to indicate the P2MP PW capability: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |U|F| TLV Code Point=0x703 | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |S| Reserved | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 5: P2MP PW LDP Capability TLV 491 Note: TLV number pending IANA allocation. 493 * U-bit: 495 SHOULD be 1 (ignore if not understood). 497 * F-bit: 499 SHOULD be 0 (don't forward if not understood). 501 * TLV Code Point: 503 The TLV type, which identifies a specific capability. The P2MP PW 504 capability code point is requested in the IANA allocation section 505 below. 507 * S-bit: 509 The State Bit indicates whether the sender is advertising or 510 withdrawing the P2MP PW capability. The State bit is used as 511 follows: 512 1 - The TLV is advertising the capability specified by the 513 TLV Code Point. 515 0 - The TLV is withdrawing the capability specified by the 516 TLV Code Point. 518 6. P2MP PW status 520 In order to support the proposed mechanism, a node MUST be capable of 521 handling PW status. As such, PW status negotiation procedure 522 described in [RFC4447] is not applicable to P2MP PW. 524 Once a Leaf-PE successfully process a Label Mapping Message for a 525 P2MP PW, it MUST send appropriate PW status according to the 526 procedure specified [RFC4447] to notify the PW status. If there is no 527 PW status notification required, then no PW status notification is 528 sent. (for example if the P2MP PW is established and operational with 529 a status 0f 0x00000000 no pw status message is necessary). 531 PW status message sent from any Leaf-PE to Root-PE contains P2MP PW 532 FEC to identify the PW. Finally, a Root-PE also sends PW status to 533 Leaf-PE(s) to reflect its view of a P2MP PW state. 535 Connectivity status of the underlying P2MP LSP that P2MP PW is 536 associated with, can be verified using LSP Ping and Traceroute 537 procedures described in [P2MP-LSP-PING]. 539 7. Security Considerations 541 The security measures described in [RFC4447] is adequate for the 542 proposed mechanism. 544 8. IANA Considerations 546 8.1. FEC Type Name Space 548 This document uses a new FEC element types, number 0x82 will be 549 requested as an allocation from the registry "FEC Type Name Space" 550 for the Label Distribution Protocol (LDP RFC5036): 552 Value Hex Name Reference 553 ------- ----- ----------------------------- --------- 554 130 0x82 P2MP PW FEC Element RFCxxxx 556 8.2. LDP TLV TYPE 558 This document uses a new LDP TLV types, IANA already maintains a 559 registry of name "TLV TYPE NAME SPACE" defined by RFC5036. The 560 following values are suggested for assignment: 562 TLV type Description 563 0x0971 Transport LSP TLV 564 0x0703 P2MP PW Capability TLV 566 8.3. mLDP Opaque Value Element TLV TYPE 568 This document requires allocation of a new mLDP Opaque Value Element 569 Type from the LDP MP Opaque Value Element type name space defined in 570 [mLDP]. 572 The following value is suggested for assignment: 574 TLV type Description 575 0x3 L2VPN-MCAST application TLV 577 9. References 579 9.1. Normative References 581 [RFC2119] Bradner. S, "Key words for use in RFCs to 582 Indicate Requirement Levels", RFC 2119, March, 1997. 584 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 585 et al., rfc4447 April 2006. 587 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 588 Specification", RFC 5036, October 2007. 590 [RFC5003] C. Metz, L. Martini, F. Balus, J. Sugimoto, "Attachment 591 Individual Identifier (AII) Types for Aggregation", RFC5003, 592 September 2007. 594 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 595 Assignment and Context-Specific Label Space", rfc5331, 596 August 2008. 598 [RFC5332] T. Eckert, E. Rosen, Ed.,R. Aggarwal, Y. Rekhter, 599 "MPLS Multicast Encapsulations", rfc5332, August 2008. 601 [mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label 602 Distribution Protocol Extensions for Point-to-Multipoint and 603 Multipoint-to-Multipoint Label Switched Paths", 604 draft-ietf-mpls-ldp-p2mp-06, Work In Progress, April 2009. 606 [RFC4875] 607 R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., 608 "Extensions to Resource Reservation Protocol - Traffic 609 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 610 Switched Paths (LSPs).", rfc4875, May 2007. 612 [L3VPN-MCAST] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, 613 "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 614 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, 615 Work in Progress, October 2009. 617 [RFC5561] B.Thomas, K.Raza, S.Aggarwal, R.Agarwal, JL. Le Roux, 618 "LDP Capabilities", rfc5561, July 2009. 620 9.2. Informative References 622 [RFC3985] Stewart Bryant, et al., "PWE3 Architecture", 623 RFC3985 625 [RFC6074] E. Rosen,W. Luo,B. Davie,V. Radoaca "Provisioning, 626 Auto-Discovery, and Signaling in Layer 2 Virtual Private 627 Networks (L2VPNs)", RFC6074, January 2011. 629 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point 630 to Multipoint Pseudowire", 631 draft-ietf-pwe3-p2mp-pw-requirements-03.txt, Work in Progress, 632 August 2010. 634 [P2MP-LSP-PING] A. Farrel, S. Yasukawa, "Detecting Data Plane 635 Failures in Point-to-Multipoint Multiprotocol Label Switching 636 (MPLS) - Extensions to LSP Ping", 637 draft-ietf-mpls-p2mp-lsp-ping-15.txt, Work In Progress, 638 January 2011. 640 10. Author's Addresses 642 Luca Martini 643 Cisco Systems, Inc. 644 9155 East Nichols Avenue, Suite 400 645 Englewood, CO, 80112 646 e-mail: lmartini@cisco.com 648 Sami Boutros 649 Cisco Systems, Inc. 650 170 West Tasman Drive 651 San Jose, CA 95134 652 e-mail: sboutros@cisco.com 654 Siva Sivabalan 655 2000 Innovation Drive 656 Kanata, ONTARIO K2K 3E8 657 CANADA 658 e-mail: msiva@cisco.com 660 Maciek Konstantynowicz 661 Juniper Networks 662 UNITED KINGDOM 663 e-mail: maciek@juniper.net 665 Gianni Del Vecchio 666 Swisscom (Schweiz) AG 667 Zentweg 9 668 CH-3006 Bern 669 Switzerland 670 e-mail: Gianni.DelVecchio@swisscom.com 672 Thomas D. Nadeau 673 Huawei Technologies 674 2330 Central Expy 675 Santa Clara, CA 95050 676 USA 677 e-mail: thomas.nadeau@huawei.com 678 Frederic Jounay 679 France Telecom 680 2, avenue Pierre-Marzin 681 22307 Lannion Cedex 682 FRANCE 683 Email: frederic.jounay@orange-ftgroup.com 685 Philippe Niger 686 France Telecom 687 2, avenue Pierre-Marzin 688 22307 Lannion Cedex 689 FRANCE 690 Email: philippe.niger@orange-ftgroup.com 692 Yuji Kamite 693 NTT Communications Corporation 694 Tokyo Opera City Tower 695 3-20-2 Nishi Shinjuku, Shinjuku-ku 696 Tokyo 163-1421 697 Japan 698 Email: y.kamite@ntt.com 700 Lizhong Jin 701 ZTE 702 889 Bibo Road, 703 Shanghai, 201203 704 P.R.China 705 Email: lizhong.jin@zte.com.cn 707 Martin Vigoureux 708 Alcatel-Lucent 709 Route de Villejust 710 Nozay, 91620 711 France 712 Email: martin.vigoureux@alcatel-lucent.com 714 Laurent Ciavaglia 715 Alcatel-Lucent 716 Route de Villejust 717 Nozay, 91620 718 France 719 Email: Laurent.Ciavaglia@alcatel-lucent.com 720 Simon Delord 721 Alcatel-Lucent 723 E-mail: simon.a.delord@team.telstra.com 725 Copyright Notice 727 Copyright (c) 2011 IETF Trust and the persons identified as the 728 document authors. All rights reserved. 730 This document is subject to BCP 78 and the IETF Trust's Legal 731 Provisions Relating to IETF Documents 732 (http://trustee.ietf.org/license-info) in effect on the date of 733 publication of this document. Please review these documents 734 carefully, as they describe your rights and restrictions with respect 735 to this document. Code Components extracted from this document must 736 include Simplified BSD License text as described in Section 4.e of 737 the Trust Legal Provisions and are provided without warranty as 738 described in the Simplified BSD License. 740 This document may contain material from IETF Documents or IETF 741 Contributions published or made publicly available before November 742 10, 2008. The person(s) controlling the copyright in some of this 743 material may not have granted the IETF Trust the right to allow 744 modifications of such material outside the IETF Standards Process. 745 Without obtaining an adequate license from the person(s) controlling 746 the copyright in such materials, this document may not be modified 747 outside the IETF Standards Process, and derivative works of it may 748 not be created outside the IETF Standards Process, except to format 749 it for publication as an RFC or to translate it into languages other 750 than English. 752 Acknowledgments 754 The authors wish to acknowledge the contributions of Ali Sajassi. 756 Expiration Date: September 2011