--- 1/draft-ietf-mpls-mldp-in-band-signaling-00.txt 2010-02-26 18:11:09.000000000 +0100 +++ 2/draft-ietf-mpls-mldp-in-band-signaling-01.txt 2010-02-26 18:11:09.000000000 +0100 @@ -1,97 +1,105 @@ Network Working Group I. Wijnands (Editor) Internet-Draft T. Eckert Intended status: Standards Track Cisco Systems, Inc. -Expires: July 22, 2010 N. Leymann +Expires: August 30, 2010 N. Leymann Deutsche Telekom M. Napierala AT&T Labs - January 18, 2010 + February 26, 2010 mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths - draft-ietf-mpls-mldp-in-band-signaling-00 + draft-ietf-mpls-mldp-in-band-signaling-01 + +Abstract + + Suppose an IP multicast tree, constructed by Protocol Independent + Multicast (PIM), needs to pass through an MPLS domain in which + Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- + Multipoint Labels Switched Paths (LSPs) can be created. The part of + the IP multicast tree that traverses the MPLS domain can be + instantiated as a multipoint LSP. When a PIM Join message is + received at the border of the MPLS domain, information from that + message is encoded into mLDP messages. When the mLDP messages are + received at the border of the next IP domain, the encoded information + is used to generate PIM messages that can be sent through the IP + domain. The result is an IP multicast tree consisting of a set of IP + multicast sub-trees that are spliced together with a multipoint LSP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 22, 2010. + This Internet-Draft will expire on August 30, 2010. Copyright Notice + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. - When an IP multicast tree needs to pass through an MPLS domain, it is - advantageous to map the tree to a Point-to-Multipoint or Multipoint- - to-Multipoint Label Switched Path. This document specifies a way to - provide a one-one mapping between IP multicast trees and Label - Switched Paths using mLDP signaling. The IP multicast control - messages are translated into MPLS control messages when they enter - the MPLS domain, and are translated back into IP multicast control - messages at the far end of the MPLS domain. The IP multicast control - information is coded into the MPLS control information in such a way - as to ensure that a single Multipoint Label Switched Path gets set up - for each IP multicast tree. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Conventions used in this document . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5 - 2.1. Transiting IP multicast source trees . . . . . . . . . . . 6 - 2.2. Transiting IP multicast bidirectional trees . . . . . . . 6 - 2.3. Transiting IP multicast shared Trees . . . . . . . . . . . 7 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions used in this document . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4 + 2.1. Transiting Unidirectional IP multicast Shared Trees . . . 5 + 2.2. Transiting IP multicast source trees . . . . . . . . . . . 5 + 2.3. Transiting IP multicast bidirectional trees . . . . . . . 6 3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7 3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7 - 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8 + 3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 7 3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 8 - 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 + 3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms @@ -102,29 +110,28 @@ particular enduser multicast packets with any particular LSP. Other drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in which out-of-band signaling protocols, such as PIM and BGP, are used to establish the mapping between an LSP and the multicast packets that need to be forwarded over the LSP. This draft describes an application in which the information needed to establish the mapping between an LSP and the set of multicast packets to be forwarded over it is carried in the "opaque value" field of an mLDP FEC element. When an IP multicast tree (either a - source-specific tree or a bidirectional tree) enters the MPLS - network, the IP multicast control messages used to set up the tree - are translated into mLDP messages. The (S,G) or (*,G) information - from the IP multicast control messages is carried in the opaque value - field of the mLDP FEC message. As the tree leaves the MPLS network, - this information is extracted from the FEC element and used to build - the IP multicast control messages that are sent outside the MPLS - domain. Note that although the IP multicast control messages are - sent periodically, the mLDP messages are not. + source-specific tree or a bidirectional tree) enters the MPLS network + the (S,G) or (*,G) information from the IP multicast control plane + state is carried in the opaque value field of the mLDP FEC message. + As the tree leaves the MPLS network, this information is extracted + from the FEC element and used to build the IP multicast control + plane. PIM messages can be sent outside the MPLS domain. Note that + although the PIM control messages are sent periodically, the mLDP + messages are not. Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in the MPLS network. This type of service works well if the number of LSPs that are created is under control of the MPLS network operator, or if the number of LSPs for a particular service are known to be limited in number. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -137,21 +144,22 @@ an source IP address and/or IP multicast destination address, also refered to as (S,G) and (*,G). mLDP : Multicast LDP. Transit LSP : An P2MP or MP2MP LSP whose FEC element contains the (S,G) or (*,G) identifying a particular IP multicast distribution tree. In-band signaling : Using the opaque value of a mLDP FEC element to - signal multicast route information. + carry the (S,G) or (*,G) indentifying a particular IP multicast + tree. P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. MP2MP LSP: An LSP that connects a set of leaf nodes, acting indifferently as ingress or egress. MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP. Ingress LSR: Source of the P2MP LSP, also referred to as root node. @@ -160,95 +168,127 @@ referred to as leaf node in the case of P2MP and MP2MP LSPs. Transit LSR: An LSR that has one or more directly connected downstream LSRs. 2. In-band signaling for MP LSPs Suppose an LSR, call it D, is attached to a network that is capable of MPLS multicast and IP multicast, and D has the desire to create IP multicast tree due to a certain IP multicast event, like a PIM Join, - MSDP Source Announcement (SA) [RFC3618] or RP discovery. Suppose - that D can determine that the IP multicast tree needs to travel - through the MPLS network until it reaches some other LSR, U. For - instance, when D looks up the route to the Source or Rendezvous Point - (RP) [RFC4601] of the IP multicast tree, it may discover that the - route is a BGP route with U as the BGP next hop. Then D may chose to - set up a P2MP or MP2MP LSP, with U as root, and to make that LSP - become part of the IP multicast distribution tree. Note that other - methods are possible to determine that an IP multicast tree is to be - transported across an MPLS network using P2MP or MP2MP LSPs, these - methods are outside the scope of this document. + MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto- + discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery. + Suppose that D can determine that the IP multicast tree needs to + travel through the MPLS network until it reaches some other LSR, U. + For instance, when D looks up the route to the Source or Rendezvous + Point (RP) [RFC4601] of the IP multicast tree, it may discover that + the route is a BGP route with U as the BGP next hop. Then D may + chose to set up a P2MP or MP2MP LSP, with U as root, and to make that + LSP become part of the IP multicast distribution tree. Note that + other methods are possible to determine that an IP multicast tree is + to be transported across an MPLS network using P2MP or MP2MP LSPs, + these methods are outside the scope of this document. Source or RP addresses that are reachable in a VPN context are outside the scope of this document. - In order to send the multicast stream via a P2MP or MP2MP LSP using - in-band signaling the source and the group will be encoded into an - mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of + Multicast groups that operate in PIM Dense-Mode are outside the scope + of this document. + + In order to transport the multicast tree via a P2MP or MP2MP LSP + using in-band signaling the source and the group will be encoded into + an mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp]. The type of encoding depends on the IP version. The tree type (P2MP or MP2MP) depends on whether this is a source specific or a bidirectional - multicast stream. The root of the tree is the BGP next-hop that was + multicast tree. The root of the tree is the BGP next-hop that was found during the route lookup on the source or RP. Using this information a mLDP FEC is created and the LSP is build towards the root of the LSP. When an LSR receives a label mapping or withdraw and discovers it is the root of the identified P2MP or MP2MP LSP, then the following - procedure will be executed. If the opaque encoding of the FEC - indicates this is an Transit LSP (indicated by the opaque type), the - opaque TLV will be decoded and the multicast source and group is - passed to the multicast code. If the multicast tree information was - received via a label mapping, the multicast code will effectively - treat this as a positif indication to create a IP multicast tree - based on the received information. If it was due to a label - withdraw, the multicast code will effectively treat this as having - received a negative indication and it will remove the tree - indentified by the encoded information. From this point on normal - PIM processing will occur. + procedure is executed. If the opaque encoding of the FEC indicates + this is a Transit LSP (indicated by the opaque type), the opaque TLV + is decoded and the multicast source and group is passed to the + multicast code. If the multicast tree information is received via a + label mapping, the multicast code will adds the downstream LDP + neighbor to the olist of the corresponding (S,G) or (*,G) state, + creating such state if it does not already exist. If it is due to a + label withdraw, the multicast code will remove the downstream LDP + neighbor from the olist of the corresponding (S,G) or (*,G) state. + From this point on normal PIM processing will occur. -2.1. Transiting IP multicast source trees +2.1. Transiting Unidirectional IP multicast Shared Trees + + Nothing prevents PIM shared trees, used by PIM-SM in the ASM service + model, from being transported across a MPLS core. However, it is not + possible to prune individual sources from the shared tree without the + use of an additional out-of-band signaling protocol, like PIM or BGP + [I-D.rekhter-pim-sm-over-mldp]. For that reason transiting Shared + Trees across a Transit LSP is outside the scope of this draft. + +2.2. Transiting IP multicast source trees IP multicast source trees can either be created via PIM operating in - SSM mode [RFC4607] or ASM mode [RFC4601] (for example via last hop - behavior or MSDP [RFC3618]) and MUST be transporting across the MPLS - network using a P2MP LSP. A Transit LSP may be setup to forward the - IP multicast traffic across an MPLS core. If the multicast source is - reachable in a global table the source and group addresses are - encoded into the a transit TLV. Depending on the IP version it is - either Section 3.1 or Section 3.2. + SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM + mode, the usual means of discovering active sources is to join a + sparse mode shared tree. However, this document does not provide any + method of transporting a sparse mode shared tree across an MPLS + network. To apply the technique of this document to PIM-SM in ASM + mode, there must be some other means of discovering the active + sources. One possible means is the use of MSDP [RFC3618]. Another + possible means is to use BGP Source Active auto-discovery routes, as + documented in [I-D.rekhter-pim-sm-over-mldp]. However, the method of + discovering the active sources is outside the scope of this document, + and as a result this document does not specify everything that is + needed to support the ASM service model using in-band signaling. -2.2. Transiting IP multicast bidirectional trees + The source and group addresses are encoded into the a transit TLV as + specified in Section 3.1 and Section 3.2. + +2.3. Transiting IP multicast bidirectional trees Bidirectional IP multicast trees [RFC5015] MUST be transported across a MPLS network using MP2MP LSPs. A bidirectional tree does not have - a specific source address; only the group address and subnet mask are - relevant for multicast forwarding. The RP for the group already - known by IP multicast is used to select the ingress PE and root of - the LSP. The group address is encoded in either Section 3.3 or - Section 3.4, depending on the IP version. The subnet mask associated - with the bidirectional group is encoded in the Transit TLV. There - are two types of bidirection states in IP multicast, the group - specific state and the RPA state. The first type is typlically - created due to receiving a PIM join and has a subnet mask of 32 for - IPv4 and 128 for IPv6, the latter is typically created via the RP - mapping protocol and has a variable subnet mask. The RPA state is - used to build a tree to the RP and used for sender only branches. - Please see [RFC5015] for more details. + a specific source address; the group address, subnet mask and RP are + relevant for multicast forwarding. This document does not provide + procedures to discover RP to group mappings dynamically across an + MPLS network and assumes the RP is statically defined. Support of + dynamic RP mappings in combination with in-band signaling is outside + the scope of his document. -2.3. Transiting IP multicast shared Trees + The RP for the group is used to select the ingress PE and root of the + LSP. The group address is encoded according to the rules of + Section 3.3 or Section 3.4, depending on the IP version. The subnet + mask associated with the bidirectional group is encoded in the + Transit TLV. There are two types of bidirectional states in IP + multicast, the group specific state and the RPA state. The first + type is typically created due to receiving a PIM join and has a + subnet mask of 32 for IPv4 and 128 for IPv6. The latter is typically + created via the static RP mapping and has a variable subnet mask. + The RPA state is used to build a tree to the RP and used for sender + only branches. Each state (group specific and RPA state) will result + in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be + done by PIM on the root LSR. No speccial procedures are nessesary + for PIM to merge the two LSPs, each LSP is effectively treated as a + PIM enabled interface. Please see [RFC5015] for more details. - Nothing prevents PIM shared trees from being transported across a - MPLS core. However, it is not possible to prune of individual - sources from the shared tree without the use of an additional out-of- - band signaling protocol, like PIM. For that reason transiting Shared - Trees across a Transit LSP is outside the scope of this draft. + In order transport the packets of sender only branch to the root of + the LSP a MP2MP is created. This will cause the sender only branches + to receive each others packets. These packets will be dropped and + not forwarded, if that affect is undesireable some other means of + transport has to be established to forward packets to the root of the + tree, like a Multi-Point to Point LSP for example. A technique to + unicast packets to the root of a P2MP or MP2MP LSP is documented in + + [I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1 and + [I-D.ietf-mpls-ldp-p2mp] section 3. 3. LSP opaque encodings This section documents the different transit opaque encodings. 3.1. Transit IPv4 Source TLV 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -397,46 +437,59 @@ 8.1. Normative References [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-mpls-ldp-p2mp] - Minei, I., "Label Distribution Protocol Extensions for - Point-to-Multipoint and Multipoint-to-Multipoint Label - Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in - progress), June 2008. + Minei, I., Kompella, K., Wijnands, I., and B. Thomas, + "Label Distribution Protocol Extensions for Point-to- + Multipoint and Multipoint-to-Multipoint Label Switched + Paths", draft-ietf-mpls-ldp-p2mp-08 (work in progress), + October 2009. 8.2. Informative References [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [I-D.ietf-l3vpn-2547bis-mcast] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in - MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work - in progress), July 2008. + MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work + in progress), January 2010. + + [I-D.rekhter-pim-sm-over-mldp] + Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode + Trees over P2MP mLDP LSPs", + draft-rekhter-pim-sm-over-mldp-00 (work in progress), + November 2009. + + [I-D.rosen-l3vpn-mvpn-mspmsi] + Boers, A., Cai, Y., Napierala, M., Rosen, E., and I. + Wijnands, "MVPN: Optimized use of PIM via MS-PMSIs", + draft-rosen-l3vpn-mvpn-mspmsi-06 (work in progress), + February 2010. Authors' Addresses IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com