Network Working Group Jong-Moon Chung Internet Draft (Oklahoma State Expiration Date: August 2002 University) Mauricio A. Subieta Benito (Oklahoma State University) Harleen Chhabra (Exxon Mobil) Grace Yoona Cho (Oklahoma State University) Pravin Rasiah (Oklahoma State University) February 2002 LDP Extensions for MPLS Multicasting Services draft-chung-mpls-ldp-multicasting-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This paper proposes the extensions necessary for the Label Distribution Protocol (LDP) to support MPLS network multicasting functionalities. The IP multicasting requirements based on the protocol procedural format (e.g., PIM-DM, PIM-SM, DVMRP, MOSPF, CBT, etc.) will be fully embedded into the LDP signaling procedures to enable multicasting operations through pure MPLS networking procedures alone. Jong-Moon Chung, et al. Page <1> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 Table of Contents 1. Introduction................................................3 2. Extensions to LDP for Multicasting in MPLS Networks.........4 2.1. Multicasting Message........................................4 2.1.1. Join Command................................................6 2.1.2. Leave Command...............................................6 2.1.3. Destroy Command.............................................6 2.2. Hello Message Extensions....................................7 2.3. Notification Message Extensions.............................7 2.4. Multicast Extensions of the Label Request Message...........7 2.5. Multicast Extensions of Label Mapping Message...............8 2.6. MPLS Multicast Forwarding Table.............................8 3. Multicasting Tree Operations................................9 3.1. Joining Mechanisms..........................................9 3.2. Multicasting Tree Construction.............................12 3.2.1. Construction of a LDP Multicasting Distribution Tree.......12 3.2.2. Root-Initiated Tree Calculation............................13 3.2.2.1.Calculation based on IGMP information.....................13 3.2.3. Leaf-Initiated Tree Calculation............................14 3.2.4. Dynamic Updates to the Tree................................15 4. Conclusions................................................16 5. References.................................................16 6. AuthorsÆ Addresses.........................................17 Abbreviations DS: Differentiated Services DVMRP: Distance Vector Multicast Routing Protocol FEC: Forwarding Equivalence Class GoS: Grade of Service IGMP: Internet Group Management Protocol LDP: Label Distribution Protocol LSP: Label Switching Path LSR-RP: Label Switching Router-Rendezvous Point MIDB: Multicast Information Database MOSPF: Multicast Open Shortest Path First MPLS: Multiprotocol Label Switching PIM-DM: Protocol Independent Multicasting-Dense Mode PIM-SM: Protocol Independent Multicasting-Sparse Mode QoS: Quality of Service RPF: Reverse Path Forwarding Jong-Moon Chung, et al. February 2002 Page <2> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 1. Introduction Multicasting can be viewed as a controlled or restricted application of broadcasting, a point-to-multipoint mechanism that allows several interested parties, namely hosts and/or routers to receive packets of information at the same time. This process requires not only a connection-oriented mechanism with high reliability and quality of service (QoS) support, but also a method of seamlessly communicating from one to many points. In Multiprotocol Label Switching (MPLS) networks, a signaling protocol that provides connection-oriented, reliable, differentiated services, and QoS is the Label Distribution Protocol (LDP). LDP sets up label-distributed paths to support data transfer in MPLS networks. LDP is a hard-state, scalable, nonproprietary traffic engineering signaling protocol that allows the creation, management, and teardown of Label Switched Paths (LSPs) in MPLS networks [10]. RFC 3036 notes that LDP support for multicast is not specified and is to be addressed in future studies [1]. Based on this, several extensions to the LDP signaling protocol are proposed in this document to support multicasting services. These extensions produce a mechanism for creating root-initiated and leaf-initiated trees for multicasting through LDP. The proposed work agrees with the framework concepts of [13] and presents operational procedures of multicasting through extensions to LDP. The basic concept is to enable MPLS networking with all the functionalities and services required for multicasting, where the addressing and management topology of current IP multicasting users and groups will be done by the Internet Group Management Protocol (IGMP)[8][9], thereby keeping the management and addressing the same, but enabling the Traffic Engineering (TE) advantages of MPLS to exist over the multicasting network connections. The protocol fields that trigger the multicasting operations of LDP as well as the procedures for creating the multicasting trees, and a means for incorporating tree calculations into LDP are provided in this document. Additionally, this document enables the multicasting functions of LDP to be independent of traditional IP-based multicast routing protocols such as DVMRP, MOSPF, PIM, etc. For the extensions to the LDP specifications defined in RFC 3036, the common multicasting functions that the IP multicast routing protocols offer, such as tree formations with Join, Leave, Destroy, and RPF messages should directly be implemented in LDP to enable MPLS based multicasting. This document also addresses the issues of aggregating LSPs for multicasting, handling and storing multicasting data in a decentralized fashion, piggybacking, and label allocation [13]. Jong-Moon Chung, et al. February 2002 Page <3> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 2. Extensions to LDP for Multicasting in MPLS Networks 2.1. Multicasting Message The Multicasting message is used to conduct a Join, Leave, or Destroy command of the multicasting tree. When a leaf-initiated Join operation must be performed, a Multicast message is sent (by means of a unicast transmission) to a LSR of the existing multicast tree to create a new LSP connection to the leaf. The Leave command is issued by a LSR to its upstream LSR when it finds that no members receiving multicasting traffic is connected to it. The Destroy command is initiated when the source stops multicasting and it wants to tear down the tree. The above commands (i.e., Join, Leave, and Destroy) can be implemented by using the Multicast Message. The Multicast message has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Message Type: Multicasting| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicasting TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree TLV (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional TVLs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields contained in the Multicast message are explained as follows: Message Type This field indicates that this message type is the Multicasting message. The coding for this message takes the standard identification format as indicated in LDP. The specific identification number is to be announced. Message length Indicates the length of the Multicast message. Message ID Indicates the identification of each message. Multicasting TLV The multicast command TLV includes three main command types, which are Join (0x0001), Leave (0x0002), and Destroy (0x0003). Jong-Moon Chung, et al. February 2002 Page <4> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 The Multicasting TLV has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Multicasting | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V| Reserved | Multicast ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Multicasting IP Source address (4 or 16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Multicasting IP Group address (4 or 16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Multicasting TLV can be used in other messages when needed. The fields contained in the Multicasting TLV message are explained as follows: V Identifies the IP protocol version. A value of zero indicates IPv4 and value of one indicates IPv6. Multicast ID A 16-bit identifier used in the session that remains constant over the life of the tunnel. This identifies different types of service sessions that are used over the same multicasting tree. Multicasting IP Source Address IPv4 (4 bytes) or IPv6 (16 bytes) address of the source node of the multicasting tree. Multicasting IP Group Address IPv4 (4 bytes) or IPv6 (16 bytes) multicasting group address used in the session that remains constant over the life of a multicasting tree connection. The three command types that can be operated by the multicasting message (Join, Leave, and Destroy commands) are explained below in sections 2.1.1, 2.1.2, and 2.1.3. The Tree TLV is used to provide a list of selected multicasting tree Label Switching Router Rendezvous Point (LSR-RP) addresses that are listed for identification purposes (as in the Hello messages) or for selected path traversing (as in the Notification messages). In this document, the LSR-RP is defined as a LSR that is functioning (or may function) as a multicasting terminal to other LSRs or hosts that will receive multicasting traffic through itself. A LSR-RP is any intermediate LSR that has two or more branches that forward traffic downstream or aggregate traffic upstream. Jong-Moon Chung, et al. February 2002 Page <5> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 The Tree TLV can be used in other LDP messages when needed. The Tree TLV has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Tree | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V| Reserved | Multicast ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Multicasting LSR-RP Address-1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . . . . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Multicasting LSR-RP Address-N ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V Identifies the IP protocol version. A value of zero indicates IPv4 and value of one indicates IPv6. IP Multicasting LSR-RP Address IPv4 (4 bytes) or IPv6 (16 bytes) address of the LSR-RPs of the multicasting tree. 2.1.1. Join Command The Join command is initiated when a LSR has identified a multicasting group that it wants to join in order to receive group specific multicasting data. The joining mechanism is reviewed in detail in section 3.1. 2.1.2. Leave Command The Leave command allows members of the multicast group to detach themselves from the group, stopping all information from the group to reach the pruned member. For example, a member may decide to stop participating in the group. In this case, a Leave command must be initiated by the receiving LSR to the upstream LSR of the multicasting tree to indicate the end of its participation. Correspondingly, the upstream LSR will send a Leave command to the root LSR such that the Multicast Information Database (MIDB) information can be updated. 2.1.3. Destroy Command The Destroy command is used when the label switched path created for the multicasting group is no longer needed. This may result due to the source not having any more data to transmit to the multicasting group members. When the destroy procedure takes place, all branches within the multicast tree are torn down to end all data flow for the Jong-Moon Chung, et al. February 2002 Page <6> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 entire group. The Destroy command is issued through the Multicasting message. As the multicasting group is no longer needed, the root LSR sends a Multicasting message with a Destroy command indication to its directly connected LSRs, which will be forwarded to other downstream LSRs. The receiving LSRs will identify this command and will disconnect from its upstream LSR through label release procedures [1]. This procedure continues until the Destroy command reaches the last LSR of the tree, which then disconnects from their upstream LSRs. 2.2. Hello Message Extensions The multicasting extensions to the Hello message include the Multicasting TLV and the Tree TLV. The Multicasting TLV is an optional TLV to the Hello message, which is used to inform the LSRs of the multicasting source and group IP address of the multicasting tree. The Tree TLV is also an optional TLV to the Hello message, which provides a list of multicasting tree LSR-RP addresses that are announced such that LSRs that are not part of the multicasting tree can identify these LSR-RP addresses for future connection purposes. 2.3. Notification Message Extensions In order to provide advisory information of a significant event to a LDP peer node, a LSR will issue a Notification message [1]. For example, the outcome of processing a LDP message or the state of the LDP session is informed using the Notification message. The Notification message contains a Status TLV that encodes the information and, on an optional basis, additional TLVs that provide more information about the condition of the network connection. The multicasting extensions to the Notification message include the Multicasting TLV and the Tree TLV. Based on applications of multicasting, Join and Leave messages require the root LSR to respond to their request with either permission for connection to the multicasting tree or requesting procedures to disconnect using label release procedures. The multicasting extensions to the Notification message serves this purposes of communication between the root LSR and the LSR-RP that needs to conduct the connection or disconnection establishments to or from the multicasting tree. 2.4. Multicast Extensions of the Label Request Message The message that allows the construction of the distribution tree is the LDP Label Request message [1]. The extensions to the Label Request message will include an optional Multicasting TLV for multicasting applications of either responding to a Join command of a multicasting message or when the multicasting tree wants a LSR to join a multicasting tree. Jong-Moon Chung, et al. February 2002 Page <7> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 2.5. Multicast Extensions of Label Mapping Message The label mapping procedure operates as defined by [1] with the option that there can be more than one outgoing label mapping for a specific incoming interface. The format of the Label Mapping message is also the same as defined in [1]. If necessary, a multicasting TLV may be used as an option. More details of the Label Mapping message are provided in the following sections. 2.6. MPLS Multicast Forwarding Table All the multicasting enabled LSRs should at least maintain the label-mapping forwarding table. The contents of the table are explained below. Interface IP The IP address of the interface on which multicasting traffic for a particular multicasting group has to be forwarded to. Multicasting Group IP Specifies the multicast address of all multicasting groups that are being serviced by the LSR. Input Label and Output Label Labels assigned to the incoming and the outgoing interfaces, respectively. Status Defines whether that particular entry in the forwarding table is pruned or active. The information included for the control of multicasting procedures in the MPLS Multicast Forwarding table is similar to the information maintained by the DVMRP Forwarding Table [17]. Jong-Moon Chung, et al. February 2002 Page <8> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 3. Multicasting Tree Operations 3.1. Joining Mechanisms The Join command is initiated when a host wants to receive multicasting traffic from the multicasting group. The LSR on whose interface the host resides initiates the Join command. There are three ways in which a host can join the multicasting group: 1. Source initiated mechanism: 1.a. Creating a new multicasting tree: When the root LSR is initially establishing the tree, a Label Request message with the multicasting TLV is sent to all LSRs that the root LSR wants to use in establishing the multicasting tree. 1.b. Adding on a LSR: The source initiated mechanism is triggered when the multicasting tree wants to include a LSR as a part of its multicasting tree. This provision has been included such that the source can build on to the multicast tree according to its necessity. The root LSR will send a Notification message with multicasting extensions (i.e., Multicasting TLV and Tree TLV) that contain the information regarding the LSR-RP that has to connect the new LSR on to the tree. The LSR-RP will then send a Label Request message to the new LSR, which will be responded by a Label Mapping message. The procedures presented in sections 3.2.1, 3.2.2, and 3.2.3 will complete the join process. (See steps 1 through 5 in the diagram below) Jong-Moon Chung, et al. February 2002 Page <9> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 Source initiated mechanism +-----------+ +-----------+ | Source +-----+ Root LSR + +-----------+ +-----+-----+ | ------->+ | | | | | (1) Notification message | | | | | V | +-----+-----+ +-----------+ +-----------+ | | LSR-RP +------+ LSR +-----+ LSR | | +-----+-----+ +-----------+ +-----------+ | | | | | | | | | | | | | V (2) Notification message | | --------------> | +-----+-----+ +-----------+ +-----------+ | | LSR-RP +------+ LSR-RP +-----+ LSR | | +-----------+ +-----------+ +-----------+ | (3) Label Request Message | <-------- | (4) Label Mapping Message | --------> V (5) Multicasting data +-------------------------------------------> 2. Control driven mechanism: We assume the presence of a root LSR that has information about every multicast group and its tree nodes. When a particular host requests for multicasting traffic from a particular group, the host will send a Join command request to the upstream LSR. The Join messageÆs Multicasting TLV may have all zero entries to the multicasting source or/and group address, which indicates that this is a request for multicasting tree information. Either the root LSR or a LSR that has information of the multicasting tree will send back a Notification message (with multicasting extensions) that contain the information regarding nodes in the receiverÆs vicinity that are nodes of the multicasting distribution tree for that particular multicasting group IP address. The multicasting information obtained is used in the Multicasting messages and the Multicasting TLV. The receiving LSR will then issue a Multicasting message with a Join command requesting connection to the multicasting tree. The procedures presented in sections 3.2.1, 3.2.2, and 3.2.3 will complete the join process. Jong-Moon Chung, et al. February 2002 Page <10> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 Control driven mechanism (2a) Join command* <--------+ +-----------+ +-----------+ | | Source +-----+ Root LSR +-----------+ | +-----------+ +-----+-----+ | | ---------+ (3)**| |(2b)Join Command*| | (1)Join Command | V | <------ | | <----- | +-----+-----+ +----+------+ +-----------+ | | LSR-RP +------+ LSR-RP +-----+ LSR 1 | | +-----+-----+ +-----------+ +-----------+ | | ---------> (4) Notification message | | (5) Label Request-------> | | | | (6) Label Mapping<------- V | +---------|---------------------------------> | (7) Multicasting Data +-----+-----+ +-----------+ +-----------+ | LSR +-----+ LSR +-----+ LSR 2 | +-----------+ +-----------+ +-----------+ * Either (2a) or (2b) will be used ** Notification Message 3. Flooding mechanism: If the LSR trying to connect to the distribution tree has no information about the multicasting LSRs around it, flooding can be used to spread the Join command. The Join messageÆs Multicasting TLV may have all zero entries in the multicasting source or/and group address, which indicate that this is a request for multicasting tree information. The flooding procedure takes place under the traffic engineering requirements. The root LSR then processes the request and sends back a Notification message (with multicasting extensions) that contain the information regarding nodes in the receiverÆs vicinity that are nodes of the multicasting distribution tree for that particular multicasting group IP address. The receiving LSR will then issue a Multicasting message with a Join command to those nodes. The procedures presented in sections 3.2.1, 3.2.2, and 3.2.3 will complete the join process. The Label Request message and Join command must include the IP multicasting group and source IP addresses using the Multicasting TLV. If the Join command is passed on from one LSR to the next LSR upstream, the IP address of the intermediate LSRs may be added on to the TREE TLV such that the path in which the tree is being formed can be identified at the root LSR. Jong-Moon Chung, et al. February 2002 Page <11> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 Flooding mechanism (2a) Join command* <--------+ +-----------+ +-----------+ | | Source +-----+ Root LSR +-----------+ | +-----------+ +-----+-----+ | | -------+ (3)**| |(2b)Join command*| | (1)Join command | V | <------ | | <----- | +-----+-----+ +----+------+ +-----------+ | | LSR-RP +------+ LSR-RP +-----+ LSR 1 | | +-----+-----+ +-----------+ +-----------+ | | --------->(4)Notification message | | (5) Label Request-------> V | (6) Label Mapping<------- +---------|----------------------------------> | (7) Multicasting Data | +-----+-----+ +-----------+ +-----------+ | LSR +-----+ LSR +-----+ LSR 2 | +-----------+ +-----------+ +-----------+ * Flooding of both (2a) and (2b) will be used ** Notification Message The Join command is sent on all the interfaces with traffic parameters. If these traffic parameters cannot be met, then a negotiation procedure of the traffic parameters takes place. 3.2. Multicasting Tree Construction Based on the LDP specification of RFC 3209 [1], each LSR in the network will announce and learn the presence of each other in the network by using LDP Hello messages. The discovery procedures provide a mechanism to enable LSRs to indicate their presence in a network by sending a Hello message periodically [1]. This message is transmitted to the LDP port at the æall routers on this subnetÆ group multicast address by means of a User Datagram Protocol (UDP) packet [1]. Given the Hello procedure of LDP [1] and the multicasting extensions of the Hello message (presented in section 2.2), this document will assume that each LSR knows of the other LSRs in the MPLS network. 3.2.1. Construction of a LDP Multicasting Distribution Tree In order to provide a mechanism for a point-to-multipoint LSP tree to be constructed, the calculation of the tree must be done by a mechanism that does not rely on external protocols or mechanisms. The calculation of the tree must be done before any other mechanisms for delivering data have been established. The tree can be constructed based on two different contexts: root-initiated tree calculation, and leaf-initiated tree calculation. The root-initiated tree calculation should be used when a new source of multicasting Jong-Moon Chung, et al. February 2002 Page <12> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 traffic is going to start delivering traffic to all the members of a group. The leaf-initiated tree calculation is implemented when a new member of a group wishes to receive the multicasting traffic, implementing a request-driven scheme. In addition, this document enables the multicasting functions of LDP to be independent of traditional IP-based multicast routing protocols, such as, DVMRP, MOSPF, PIM, etc. However, IGMP mechanisms will be used to provide the functionalities for establishing and maintaining multicasting group memberships. Some key issues in constructing the tree are the Traffic Engineering (TE) parameters that provide the Differentiated Services (DS) [10] and Quality of Service (QoS) features. With these considerations, the tree can be built based on: 1. Tree construction by means of source controlled routing, 2. Tree calculation by means of using traditional algorithms such as the distance vector (DV) or link state (LS) algorithms that are solely based on distance oriented metric values, or 3. Tree calculation by means of enhanced versions of the DV or LS algorithms that employ both TE parameters and distance oriented cost values as metric values in the tree calculations. 3.2.2. Root-Initiated Tree Calculation The calculation and construction of the tree must be performed based on the nodes/LSRs that have active members (hosts) that wish to receive multicasting traffic. We assume that they have been either pre-defined (by means of exchanging Hello messages) or they will be joining dynamically following a random behavior. To properly calculate the tree, an IGMP group definition table is needed in order to proceed. This information is stored in a Multicasting Information Database (MIDB) table located in all of the participating LSRs. If the IGMP information is not available, then the tree can be calculated by using the Hello message multicasting extensions described in section 2.2. 3.2.2.1. Calculation based on IGMP information Based on the IGMP membership information for a specific group, the calculation for the tree can be done quickly based on one of the methods described in Section 3.2.1. For example, extensions to the Bellman-Ford algorithm allow the construction of a distribution tree to be based on the Traffic Engineering parameters and the metric/cost criteria, rather than just the metric criteria. These extensions allow the creation of a shortest path tree that meets TE requirements from a specific source in order to deliver multicasting traffic complying with the DS and QoS parameters. The definition of these extensions is beyond the scope of this document. Jong-Moon Chung, et al. February 2002 Page <13> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 With the information gathered and stored in the MIDB, the root LSR constructs the distribution tree (step (1)). The root LSR will send out Label Request messages to the LSRs of the multicasting tree to establish a LSP tree connection (step (2)). This will be confirmed by Label Mapping messages at each link of the multicasting tree (not shown in the figure). After the tree connection is completed the source starts multicasting traffic through the root LSR to the LSRs in the multicasting tree composed by steps (3) through (7). Distribution Calculation based on MIDB information +-----------+ | MIDB | +-----+-----+ (3)Multicasting | |(1)Multicasting Tree |(2)Label Request Traffic | V Database Information| message is sent +-----------+ --> +-----+-----+ V to all LSRs of | Source +-----+ Root LSR | the tree. +-----------+ +-----+-----+ | |(4)Multicasting Traffic | V (5) (6) +-----+-----+ --> +-----------+ --> +-----------+ | LSR +-----+ LSR +-----+ Receiver 1| +-----+-----+ +-----------+ +-----------+ | |(5) | V (6) (7) +-----+-----+ --> +-----------+ --> +-----------+ | LSR +-----+ LSR +-----+ Receiver 2| +-----------+ +-----------+ +-----------+ 3.2.3. Leaf-Initiated Tree Calculation Since the distribution tree cannot be assumed static, a mechanism that allows dynamic calculation of the trees is necessary. A tree is normally recalculated when a node has to either join or leave the tree issuing the corresponding recalculation messages. The proposed messages to enable MPLS multicasting operations with LDP are defined in the following sections. For the calculation of a tree, there must be an existing multicasting source; hence the leaf-initiated tree topology establishment is based on a predefined source already multicasting. We assume that the mechanisms that provide authentication and authorization services are provided for the MPLS network, and that the verification takes place for every node that requests multicasting traffic. When a new host (i.e., leaf node) wants to become a part of the multicasting tree, it will send a LDP Multicast message with a Join command to one of the LSR-RPs. The receiving LSR-RP will send this Join command (Multicasting message) to the root LSR. If the leaf node is granted permission to join the multicasting tree the root LSR will initiate a Notification message (with multicasting extensions) towards a LSR-RP. This LSR-RP will be the selected LSR to establish a connection to the new host, where this LSR-RP may or Jong-Moon Chung, et al. February 2002 Page <14> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 may not be the LSR-RP that the new host originally contacted with the Join command. The selected LSR-RP will then issue a Label Request message to the new host to establish a new LSP. The Notification message used by the root LSR may have the multicasting extensions of section 2.3. Leaf-Initiated Tree Calculation +---------+ +-----------+ | Source +---+ Root LSR + +---------+ +-----+-----+ (3)Notification| | ^ (2)Join (1)Join Command Message with | | | Command (Multicasting Message) Multicasting V | +---- <------- Extensions+-----+-----+ +-----------+ +------------+ | LSR-RP +-----+ LSR-RP +-----+ New LSR | +-----+-----+ +-----------+ +------------+ | ----------> -------> | (4)Notification (5)Label Request Message | Message <------- | (6)Label Mapping Message | +-----+-----+ +-----------+ | LSR +-----+ LSR + +-----------+ +-----------+ 3.2.4. Dynamic Updates to the Tree Given the dynamic nature of the trees, constant adjustments to the tree have to be performed. When a LSR does not have any more multicasting receivers, it will issue a Multicasting message with a Leave command, which will be sent to the upstream LSR in order to stop the multicast traffic. The upstream LSRs will perform the following procedures: 1. If the LSR that is leaving is not the last LSR within the tree, then the upstream LSR will send a Leave command to its upstream LSR-RP, where this LSR-RP will then issue a Leave command to the root LSR. The root LSR can recalculate the tree should it be necessary; otherwise the root LSR will use this information to request an update of the label mapping tables of the LSRs along the multicasting tree. The information in the MIDB will also be updated. The root LSR will send a Notification message (with Multicasting extensions) to the LSR-RP. Following this, the LDP standard label release procedures will be conducted over the connection between the LSR-RP and the leaving LSR [1]. 2. If a tree recalculation is conducted, the root LSR will trigger a re-calculation procedure via a Notification message so all the LSRs can use the updated LSR-RP information in the MIDB. 3. If the LSR that is leaving is the last leaf LSR on the multicasting tree, then the upstream LSR will in turn issue a Multicasting message with a Leave command to the root LSR. The Jong-Moon Chung, et al. February 2002 Page <15> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 MIDB table will then be updated. The root LSR in turn (after receiving the message and recalculating the tree) will trigger a recalculation procedure via a Notification message so all the nodes can use the updated information in the MIDB. 4. If the leaving LSR is the last one connected to the root LSR (that is, the root LSR will be the last node on the tree), then the Label Release procedures will be conducted to disconnect the LSR. A destroy procedure will be used only when necessary, otherwise, the multicasting session will be kept alive, such that new users can establish a new multicasting tree if necessary. 5. In the event that the source has no more multicast content to multicast, it will issue a Multicasting message with a Destroy command that will notify all the LSRs in the tree that the label mappings have to be released, and all the multicasting traffic forwarding should be stopped. This will also trigger a purge procedure within the MIDB, clearing all the entries for the specific multicasting group. 4. Conclusions Achieving multicasting based on traffic engineering constraints is feasible by means of extending the capabilities of the LDP. By using the LDP TE constraints, the necessary guarantees for end-to-end traffic delivery can be provided, allowing service providers or carrier companies to ensure customer data transmission to be effective and allow service agreements to be maintained. The use of the multicasting extensions to LDP dramatically reduces the overhead generated in comparison to using multicasting routing protocols as middleware between the IP and data link layers. Specifically, by including the Multicasting TLV, and having the Join, Leave, and Destroy commands as part of the Multicasting message in conjunction with IGMP capabilities, the complete construction of a multicasting distribution tree using only IP multicast addressing information is possible. 5. References [1] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and Thomas, B., ææLDP Specifications,ÆÆ RFC 3036, Jan. 2001. [2] Bradner, S., ææThe Internet Standards Process,ÆÆ RFC 2026, Oct. 1996. [3] Awduche, D., Malcolm, J., Agogbua, J., OÆDell, M., and McManus, J., ææRequirements for Traffic Engineering Over MPLSÆÆ, RFC 2702, Sept. 1999. [4] Chung, J.-M., (Invited Paper) ææAnalysis of MPLS Traffic EngineeringÆÆ, in Proc. IEEE Midwest Symposium on Circuits and Systems 2000 (MWSCASÆ00), East Lansing, Michigan, USA, Aug. 8- 11, 2000. [5] Chung, J. -M., Marroun, E., Sandhu, H., and Kim, S.-C., ææVoIP over MPLS Networking Requirements.ÆÆ in Proc. IEEE International Conference on Networking 2001 (ICNÆ01), Colmar, France, July 9- 13, 2001. Jong-Moon Chung, et al. February 2002 Page <16> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 [6] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y., Rasiah, P., and Soo, H. M., ææRSVP Extensions for MPLS Multicasting Services,ÆÆ submitted, IEEE Network. [7] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y., and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ submitted, IEEE Network. [8] Deering, S., ææHost Extensions for IP Multicasting,ÆÆ RFC 1112, August 1989. [9] Fenner, W., ææInternet Group Management Protocol, Version 2,ÆÆ RFC 2236, Nov. 1997. [10] Jamoussi, B., Aboul-Magd, O., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T. Malis, A., and Vaananen, P., ææConstraint-Based LSP Setup using LDP,ÆÆ work in progress. [11] Miller, K. C., Multicast Networking and Applications. Addison- Wesley, 1999. [12] Moy, J., ææMulticast Extensions to OSPF,ÆÆ RFC 1584, Mar. 1994. [13] Ooms, D., Sales, R., Livens, W., Acharaya, A., Griffoul, F., and Ansari, F., ææFramework for IP Multicast in MPLS,ÆÆ work in progress. [14] Rosen, E., Viswanathan, A., and Callon, R., ææMultiprotocol Label Switching Architecture,ÆÆ RFC 3031, Jan. 2001. [15] Thomas, B., and Gray, E., ææLDP Applicability,ÆÆ RFC 3037, Jan. 2001. [16] Whitmann, R. and Zitterbart, M., Multicasting Communication Protocols and Applications. Morgan Kaufman Publishers, 1999. [17] Williamson, B., Developing Multicasting Networks. Vol. I, Cisco Press, 2000. 6. AuthorsÆ Addresses Jong-Moon Chung ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-9924 Email: jchung_osu@lycos.com Mauricio A. Subieta Benito ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-5215 Email: maurici@okstate.edu Harleen Chhabra Exxon Mobil P.O. Box 4449 Houston, TX 77210-4449 Phone: (713)431-4106 Jong-Moon Chung, et al. February 2002 Page <17> Internet Draft draft-ietf-mpls-ldp-multicasting-00.txt August, 2002 Email: Harleen.Chhabra@exxonmobil.com Grace Yoona Cho ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-5215 Email: chog@okstate.edu Pravin Rasiah ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-2662 Email: pravinras10@lycos.com Jong-Moon Chung, et al. February 2002 Page <18>