idnits 2.17.1 draft-wijnands-mpls-in-band-signaling-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-wijnands-mpls-mldp-in-band-signaling-00', but the file name used is 'draft-wijnands-mpls-in-band-signaling-00' 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 date (September 8, 2008) is 5708 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) == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-05 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. '4') (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Wijnands (Editor) 3 Internet-Draft T. Eckert 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: March 12, 2009 N. Leymann 6 Deutsche Telekom 7 M. Napierala 8 AT&T Labs 9 September 8, 2008 11 In-band signaling for Point-to-Multipoint and Multipoint-to-Multipoint 12 Label Switched Paths 13 draft-wijnands-mpls-mldp-in-band-signaling-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 12, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 When an IP multicast tree needs to pass through an MPLS domain, it is 47 advantageous to map the tree to a Point-to-Multipoint or Multipoint- 48 to-Multipoint Label Switched Path. This document specifies a way to 49 provide a one-one mapping between IP multicast trees and Label 50 Switched Paths. The IP multicast control messages are translated 51 into MPLS control messages when they enter the MPLS domain, and are 52 translated back into IP multicast control messages at the far end of 53 the MPLS domain. The IP multicast control information is coded into 54 the MPLS control information in such a way as to ensure that a single 55 Multipoint Label Switched Path gets set up for each IP multicast 56 tree. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions used in this document . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4 64 2.1. Transiting IP multicast source trees . . . . . . . . . . . 5 65 2.2. Transiting IP multicast bidirectional trees . . . . . . . 5 66 2.3. Transiting IP multicast shared Trees . . . . . . . . . . . 6 67 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 6 69 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 7 70 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 7 71 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Intellectual Property and Copyright Statements . . . . . . . . . . 12 82 1. Introduction 84 The mLDP specification [3] describes mechanisms for creating point- 85 to-multipoint (P2MP) and multipoint-to-multipoint MP2MP LSPs. These 86 LSPs are typically used for transporting enduser multicast packets. 87 However, the mLDP specification [3] does not provide any rules for 88 associating particular enduser multicast packets with any particular 89 LSP. Other drafts, like [7], describe applications in which out-of- 90 band signaling protocols, such as PIM and BGP, are used to establish 91 the mapping between an LSP and the multicast packets that need to be 92 forwarded over the LSP. 94 This draft describes an application in which the information needed 95 to establish the mapping between an LSP and the set of multicast 96 packets to be forwarded over it is carried in the "opaque value" 97 field of an mLDP FEC element. When an IP multicast tree (either a 98 source-specific tree or a bidirectional tree) enters the MPLS 99 network, the IP multicast control messages used to set up the tree 100 are translated into mLDP messages. The (S,G) or (*,G) information 101 from the IP multicast control messages is carried in the opaque value 102 field of the mLDP FEC message. As the tree leaves the MPLS network, 103 this information is extracted from the FEC element and used to build 104 the IP multicast control messages that are sent outside the MPLS 105 domain. Note that although the IP multicast control messages are 106 sent periodically, the mLDP messages are not. 108 Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in 109 the MPLS network. This type of service works well if the number of 110 LSPs that are created is under control of the MPLS network operator, 111 or if the number of LSPs for a particular service are known to be 112 limited in number. 114 1.1. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [2]. 120 1.2. Terminology 122 IP multicast tree : An IP multicast distribution tree identified by 123 an source IP address and/or IP multicast destination address, also 124 refered to as (S,G) and (*,G). 126 mLDP : Multicast LDP. 128 Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the 129 (S,G) or (*,G) identifying a particular IP multicast distribution 130 tree. 132 In-band signaling : Using the opaque value of a mLDP FEC element to 133 signal multicast route information. 135 P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 136 LSRs. 138 MP2MP LSP: An LSP that connects a set of leaf nodes, acting 139 indifferently as ingress or egress. 141 MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. 143 Ingress LSR: Source of the P2MP LSP, also referred to as root node. 145 Egress LSR: One of potentially many destinations of an LSP, also 146 referred to as leaf node in the case of P2MP and MP2MP LSPs. 148 Transit LSR: An LSR that has one or more directly connected 149 downstream LSRs. 151 2. In-band signaling for MP LSPs 153 Suppose an LSR, call it D, is attached to a network that is capable 154 of MPLS multicast and IP multicast, and D receives a PIM Join from 155 the IP multicast interface. The PIM Join identifies a particular IP 156 multicast tree. Suppose that D can determine that the IP multicast 157 tree needs to travel through the MPLS network until it reaches some 158 other LSR, U. For instance, when D looks up the route to the Source 159 or Rendezvous Point (RP) [4] of the IP multicast tree, it may 160 discover that the route is a BGP route with U as the BGP next hop. 161 Then D may chose to set up a P2MP or MP2MP LSP, with U as root, and 162 to make that LSP become part of the IP multicast distribution tree 163 identified by the PIM Join. Note that other methods are possible to 164 determine that an IP multicast tree is to be transported across an 165 MPLS network using P2MP or MP2MP LSPs. These methods are out of 166 scope of this document. 168 Source or RP addresses that are reachable in a VPN context are out 169 the scope of this draft. 171 In order to send the multicast stream via a P2MP or MP2MP LSP using 172 in-band signaling the source and the group will be encoded into an 173 mLDP opaque TLV encoding [3]. The type of encoding depends on the IP 174 version. The tree type (P2MP or MP2MP) depends on whether this is a 175 source specific or a bidirectional multicast stream. The root of the 176 tree is Ingress LSR that was found during the route lookup on the 177 source or RP. Using this information a mLDP FEC is created and the 178 LSP is build towards the root of the LSP. 180 When an LSR receives a label mapping or withdraw and discovers it is 181 the root of the identified P2MP or MP2MP LSP, then the following 182 procedure will be executed. If the opaque encoding of the FEC 183 indicates this is an Transit LSP (indicated by the opaque type), the 184 opaque TLV will be decoded and the multicast source and group is 185 passed to the multicast code. If the multicast tree information was 186 received via a label mapping, the multicast code will effectively 187 treat this as having received a PIM join from the MPLS network. If 188 it was due to a label withdraw, the multicast code will effectively 189 treat this as having received a PIM prune from the MPLS network. 190 From this point on normal PIM process will occur and multicast 191 packets are forwarded to the LSP or pruned from the LSP. 193 2.1. Transiting IP multicast source trees 195 IP multicast source trees can either be created via PIM operating in 196 SSM mode [5] or ASM mode [4] and MUST be transporting across the MPLS 197 network using a P2MP LSP. A Transit LSP may be setup to forward the 198 IP multicast traffic across an MPLS core. If the multicast source is 199 reachable in a global table the source and group addresses are 200 encoded into the a transit TLV. Depending on the IP version it is 201 either Section 3.1 or Section 3.2. 203 2.2. Transiting IP multicast bidirectional trees 205 Bidirectional IP multicast trees [6] MUST be transported across a 206 MPLS network using MP2MP LSPs. A bidirectional tree does not have a 207 specific source address; only the group address and subnet mask are 208 relevant for multicast forwarding. The RP for the Multicast group is 209 used to select the ingress PE and root of the LSP. How the RP is 210 discovered for the multicast group is out the scope of this document. 211 The group address is encoded in either Section 3.3 or Section 3.4, 212 depending on the IP version. The subnet mask associated with the 213 bidirectional group is encoded in the Transit TLV. IP Multicast 214 bidirectional state created due to a PIM join typically has a subnet 215 mask of 32 for IPv4 and 128 for IPv6. IP Multicast bidirectional 216 state created for a sender only branch has a variable subnet mask 217 that is assigned by the RP mapping protocol. 219 2.3. Transiting IP multicast shared Trees 221 Nothing prevents PIM shared trees from being transported across a 222 MPLS core. However, it is not possible to prune of individual 223 sources from the shared tree without the use of an additional out-of- 224 band signaling protocol, like PIM. For that reason transiting Shared 225 Trees across a Transit LSP is out the scope of this draft. 227 3. LSP opaque encodings 229 This section documents the different transit opaque encodings. 231 3.1. Transit IPv4 Source TLV 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type | Length | Source 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Group 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Type: 2 (to be assigned by IANA). 245 Length: 8 247 Source: IPv4 multicast source address, 4 octets. 249 Group: IPv4 multicast group address, 4 octets. 251 3.2. Transit IPv6 Source TLV 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | Source ~ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 ~ | Group ~ 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 ~ | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Type: 3 (to be assigned by IANA). 265 Length: 32 267 Source: IPv6 multicast source address, 16 octets. 269 Group: IPv6 multicast group address, 16 octets. 271 3.3. Transit IPv4 bidir TLV 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | Mask Len | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Group | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Type: 4 (to be assigned by IANA). 283 Length: 5 284 Mask Len: The number of contiguous one bits that are left justified 285 and used as a mask, 1 octet. 287 Group: IPv4 multicast group address, 4 octets. 289 3.4. Transit IPv6 bidir TLV 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Mask Len | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Group ~ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 ~ | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Type: 4 (to be assigned by IANA). 303 Length: 17 305 Mask Len: The number of contiguous one bits that are left justified 306 and used as a mask, 1 octet. 308 Group: IPv6 multicast group address, 16 octets. 310 4. Security Considerations 312 The same security considerations apply as for the base LDP 313 specification, as described in [1]. 315 5. IANA considerations 317 This document requires allocation from the LDP MP Opaque Value 318 Element type name space managed by IANA. The values requested are: 320 Transit IPv4 Source TLV type - requested 2 321 Transit IPv6 Source TLV type - requested 3 323 Transit IPv4 Bidir TLV type - requested 4 325 Transit IPv6 Bidir TLV type - requested 5 327 6. Acknowledgments 329 Thanks to Eric Rosen for his valuable comments on this draft. 331 7. Contributing authors 333 Below is a list of the contributing authors in alphabetical order: 335 Toerless Eckert 336 Cisco Systems, Inc. 337 170 Tasman Drive 338 San Jose, CA, 95134 339 USA 340 E-mail: eckert@cisco.com 342 Nicolai Leymann 343 Deutsche Telekom 344 Goslarer Ufer 35 345 Berlin, 10589 346 Germany 347 E-mail: nicolai.leymann@t-systems.com 349 Maria Napierala 350 AT&T Labs 351 200 Laurel Avenue 352 Middletown, NJ 07748 353 USA 354 E-mail: mnapierala@att.com 356 IJsbrand Wijnands 357 Cisco Systems, Inc. 358 De kleetlaan 6a 359 1831 Diegem 360 Belgium 361 E-mail: ice@cisco.com 363 8. References 365 8.1. Normative References 367 [1] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", 368 RFC 5036, October 2007. 370 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 371 Levels", BCP 14, RFC 2119, March 1997. 373 [3] Minei, I., "Label Distribution Protocol Extensions for Point-to- 374 Multipoint and Multipoint-to-Multipoint Label Switched Paths", 375 draft-ietf-mpls-ldp-p2mp-05 (work in progress), June 2008. 377 8.2. Informative References 379 [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 380 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 381 Specification (Revised)", RFC 4601, August 2006. 383 [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 384 RFC 4607, August 2006. 386 [6] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 387 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", 388 RFC 5015, October 2007. 390 [7] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, 391 E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP 392 VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work in progress), 393 July 2008. 395 Authors' Addresses 397 IJsbrand Wijnands 398 Cisco Systems, Inc. 399 De kleetlaan 6a 400 Diegem 1831 401 Belgium 403 Email: ice@cisco.com 404 Toerless Eckert 405 Cisco Systems, Inc. 406 170 Tasman Drive 407 San Jose CA, 95134 408 USA 410 Email: eckert@cisco.com 412 Nicolai Leymann 413 Deutsche Telekom 414 Goslarer Ufer 35 415 Berlin 10589 416 Germany 418 Email: nicolai.leymann@t-systems.com 420 Maria Napierala 421 AT&T Labs 422 200 Laurel Avenue 423 Middletown NJ 07748 424 USA 426 Email: mnapierala@att.com 428 Full Copyright Statement 430 Copyright (C) The IETF Trust (2008). 432 This document is subject to the rights, licenses and restrictions 433 contained in BCP 78, and except as set forth therein, the authors 434 retain all their rights. 436 This document and the information contained herein are provided on an 437 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 438 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 439 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 440 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 441 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 442 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 444 Intellectual Property 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org. 468 Acknowledgment 470 Funding for the RFC Editor function is provided by the IETF 471 Administrative Support Activity (IASA).