INTERNET DRAFT Seisho Yasukawa draft-yasukawa-mpls-rsvp-multicast-00.txt Masanori Uga Expires: December 2002 Hisashi Kojima Koji Sugisono NTT June 2002 Extended RSVP-TE for Multicast LSP Tunnels 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. Yasukawa, Uga, Kojima, Sugisono [Page 1] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 Table of Contents 1. Introduction ................................................... 3 2. Terminology .................................................... 3 3. Architecture ................................................... 5 3.1 Multicast LSP tunnels ...................................... 5 3.2 Multicast LSP topology ..................................... 7 3.3 Calculation of multicast tree route ........................ 7 3.4 Multicast LSP establishment, teardown, and modification mechanisms ................................................. 8 3.5 Basic operation of multicast LSP tunnels ................... 9 3.6 Multicast session ..........................................11 3.6.1 Multicast session object ..............................11 3.6.2 MULTICAST_LSP_TUNNEL_IPv4 session object ..............11 3.6.3 MULTICAST_LSP_TUNNEL_IPv6 session object ..............11 3.7 Explicit routing ...........................................11 3.7.1 Tree Explicit Route Object (TERO) .....................11 3.7.2 Tree Record Route Object (TRRO) .......................15 4. Sender-initiated multicast LSP establishment ...................18 4.1 Sender-initiated Multicast LSP establishment mechanism .....18 4.2 Process of sender-initiated multicast LSP establishment ....19 4.3 Teardown mechanism .........................................20 4.4 Path/Resv error ............................................20 4.5 Message format .............................................21 4.5.1 Path message format ...................................21 4.5.2 Resv message format ...................................21 4.5.3 PathTear message format ...............................22 4.5.4 PathErr message format ................................22 4.5.5 ResvErr Message format ................................22 5. Sender-initiated grafting/pruning mechanism ....................23 5.1 Sender-initiated grafting mechanism ........................23 5.2 Sender-initiated pruning mechanism .........................26 6. Leaf-initiated multicast LSP establishment .....................28 6.1 Leaf-initiated joining mechanism ...........................28 6.2 Join Error .................................................30 6.3 Leave-initiated leaving mechanism ..........................31 6.4 Message format .............................................32 6.4.1 Join message format ...................................32 6.4.2 JoinNotify message format .............................32 6.4.3 JoinErr message format ................................33 6.4.4 Leave message format ..................................33 6.4.5 LeaveNotify Message ...................................33 7. Multi-point to multi-point multicasting ........................33 7.1 MPLS Rendezvous Point (MRP) ................................33 7.2 Add mechanism ..............................................34 7.3 Add message format .........................................35 8.Application for Traffic Engineering .............................36 8.1 Rerouting Traffic Engineered Multicast Tunnels .............36 Yasukawa, Uga, Kojima, Sugisono [Page 2] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 8.2 Re-establishment of subtree ................................37 9. Security Considerations ........................................37 10. References ....................................................37 AUTHORS' ADDRESSES ................................................38 1. Introduction Multicast technology will become increasingly important with the dissemination of new applications such as contents delivery services and video conferences, which require much more bandwidth and stricter QoS than conventional applications. From the service providers' perspective, traffic engineering (TE) functions will be needed to handle the large amount of multicast traffic. This document defines some protocol extensions to the existing RSVP- TE[1] in order to establish a multicast label switched path (LSP). The use of label switching routers (LSRs) with these protocol extensions defined in this document allows service providers to offer unicast and multicast multiprotocol label switching (MPLS) services in the same service network. This protocol assumes a variable LSP topology, e.g., point-to- multipoint, multipoint-to-multipoint, topologies. This document describes how to establish point-to-multipoint and multipoint-to- multipoint LSPs as the most basic multicast topology. It defines two ways of constructing a point-to-multipoint LSP: sender-initiated LSP setup and leaf-initiated LSP setup. Each method has an LSP modification function in order to adapt to dynamic changes in the LSP tree topology. This MPLS architecture[10] is very flexible and can be expanded to carry protocols other than IP multicasting, e.g., Ethernet, PPP, and SONET/SDH, but this document only defines IP multicasting (IPv4 and IPv6) as a forwarding equivalence class object (FEC). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5]. The reader is assumed to be familiar with the terminology in [1], [2], [3] and [4]. Yasukawa, Uga, Kojima, Sugisono [Page 3] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 Multicast LSP: A label switched path that has more than one egress label switching router Branch LSR: A label switching router (LSR) that has more than one downstream LSR. A branch LSR receives a single MPLS frame, makes a duplicate of it, and sends each to downstream interfaces. join leaf node: A leaf node trying to join a multicast LSP. leave leaf node: A leaf node trying to leave a multicast LSP that it has joined graft/prune node: An LSR that receives a Graft/Prune message from a sender LSR and has the responsibility to add/delete the downstream subtree specified in the message. MPLS Rendezvous Point (MRP): The node binding inputs point-to-point LSP and outputs point-to- multipoint LSP. It is mainly used to support multipoint-to- multipoint topology. Explicit Route Object (ERO): An object specifying the explicit path of the message including the object. Tree Explicit Route Object (TERO): An extended ERO for describing the multicast tree topology. Record Route Object (RRO): An object recording the information of route through which the message including the object has passed. Tree Record Route Object (TRRO): An extended RRO for recording the route along which each merged Yasukawa, Uga, Kojima, Sugisono [Page 4] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 message has traveled. 3. Architecture 3.1 Multicast LSP tunnels This protocol defines "multicast flow" by a label that is assigned to a set of packets at the ingress node of a point-to-multipoint LSP. Such a point-to-multipoint LSP is referred to as a "multicast LSP tunnel" because the traffic through it is opaque to intermediate nodes along the LSP. To enable the identification and association of such multicast LSP tunnels, new MULTICAST_LSP_TUNNEL session objects are defined. Each session object carries the sender node address of a point-to-multipoint LSP and its tunnel ID. The sender node address is more preferable than destination (leaf) node addresses to identify a multicast LSP tunnel because frequent topological changes may occur and destination node addresses are not stable in this tunnel. Therefore, the SENDER_TEMPLATE (or FILTER_SPEC) object together with this SESSION object uniquely identify a multicast LSP tunnel. To identify the leaf and topology of this multicast LSP tunnel, TREE_EXPLICIT_ROUTE object and TREE_RECORD_ROUTE object are also defined. It is very useful to associate sets of LSP tunnels in a multicast application. This can be useful during rerouting operations or to spread a traffic trunk over multiple multicast paths [1]. In traffic engineering such sets are called multicast traffic engineered tunnels (multicast TE tunnels). The TE tunnel is uniquely defined by the SESSION object. 3.2 Multicast LSP topology This multicast MPLS protocol supports point-to-multipoint and multipoint-to-multipoint LSP tunnels establishment, teardown, and modification mechanisms. A point-to-multipoint LSP can handle i) (S,G) multicast traffic, ii) ({S},G), (*,G) multicast traffic, and iii) ({S},{G}) multicast traffic. (S,G) represents a single sender node with source address S transmitting multicast traffic to a multicast group G. The ({S},G) represents several sender nodes with source addresses {S} transmitting multicast traffic to a multicast group G. The (*,G) represents arbitrary sender nodes transmitting multicast traffic to a multicast group G. The ({S},{G}) represents several sender nodes with source addresses {S} transmitting multicast traffic to multicast groups {G}. Traffic that shares the same multicast distribution topology and is treated in the same forwarding manner is defined as belonging to the same FEC. Yasukawa, Uga, Kojima, Sugisono [Page 5] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 +----+ | S | +----+ | G | S: Sender V N: Node +---+ L: Leaf node | N | +---+ (S,G) | | +---+ +---+ | | +---+ +---+ | N | | N | +---+ +---+ || || || || +-++-+ +-++-+ | | | | V V V V +---++---+ +---++---+ | L || L | | L || L | +---++---+ +---++---+ +----+ +----+ | S1 | | Sn | +----+ +----+ G| |G +--+ +--+ | | S: Sender V V N: Node +---+ L: Leaf node | N | +---+ (*,G),({S}),G) | | +---+ +---+ | | +---+ +---+ | N | | N | +---+ +---+ || || +-++-+ +-++-+ | | | | V V V V +---++---+ +---++---+ | L || L | | L || L | +---++---+ +---++---+ Yasukawa, Uga, Kojima, Sugisono [Page 6] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 +----+ +----+ | S1 | | Sn | +----+ +----+ G1| |Gn +--+ +--+ | | S: Sender V V N: Node +---+ L: Leaf node | N | +---+ ({S},{G}),(*,*) || || +---+| |+---+ |+---+ +---+| || || +---+ +---+ | N | | N | +---+ +---+ || || || || ++| |++ ++| |++ |++ ++| |++ ++| || || || || VV VV VV VV +---++---+ +---++---+ | L || L | | L || L | +---++---+ +---++---+ Figure 1: Multicast traffic type This protocol can also establish an multipoint-to-multipoint LSP tunnel by combining several point-to-point LSP tunnels and a single point-to-multipoint LSP tunnel at an MPLS rendezvous point (MRP). The MRP binds point-to-point LSP tunnels and a point-to-multipoint LSP tunnel. Therefore, data traffic is forwarded from sender nodes to leaf nodes in this multipoint-to-multipoint LSP tunnel. 3.3 Calculation of multicast tree route There are two methods of calculating the multicast tree route. It can be calculated by: i) the sender node or the network management system (NMS) and ii) a IP multicast routing protocol such as PIM-SM[8]. Though the first method is suitable to achieve traffic engineering, the calculation load concentrates on the sender node or NMS. The second method can use the existing multicast routing protocol, but it is necessary to establish a method for cooperating with this protocol. This cooperation is a topic for further study. This draft assumes the first method is used. Yasukawa, Uga, Kojima, Sugisono [Page 7] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 3.4 Multicast LSP establishment, teardown, and modification mechanisms This multicast MPLS protocol can be applied to various multicast applications because it supports both sender-initiated and leaf- initiated multicast LSP tunnel establishment mechanisms. It is preferable for multicast sender nodes to start traffic distribution only after they have confirmed the establishment of an end-to-end LSP. For this, we can use the sender-initiated multicast LSP tunnel establishment mechanism. This mechanism is also preferable when establishing a QoS-capable multicast LSP tunnel because the single sender node can calculate the optimum multicast LSP tunnel using QoS information. On the other hand, some applications need a leaf-initiated multicast LSP tunnel establishment mechanism. Nodes except for sender nodes can establish and modify a multicast LSP tunnel optimally according to the client's content viewing status. A leaf node that implements IGMP[6,7] protocol in addition to this multicast MPLS protocol can dynamically invoke the multicast LSP tunnel setup mechanism according to the multicast client's content viewing status. If all the clients accommodated at the leaf node stop receiving multicast traffic from this node (e.g., all clients send a IGMP leave message to the leaf node), the leaf node invokes this process and requests to tear down unnecessary multicast LSP tunnels. If a client accommodated at the leaf node starts receiving multicast traffic from this node (e.g., a client who wants to receive this multicast data sends an IGMP Join message to the leaf node), the leaf node invoke this process and grafts the necessary multicast LSP tunnel. We must assume the co-existence of both applications in this multicast MPLS network. Therefore, the multicast MPLS protocol supports implement both sender- and leaf-initiated multicast LSP tunnel establishment mechanisms, and these mechanisms must work in an interoperable manner. Traffic engineering is more important in a multicast network environment than a unicast one. Frequent topological changes may occur in a multicast LSP tunnel because it has many leaf nodes and a more complex transmission topology. We need a more reliable tunnel re-establishment mechanism in a multicast network environment because the nodes near to root node need greater reliability than ones placed at leaf neighbors. For these demands, a partial multicast LSP tunnel modification mechanism (subtree expansion and reduction mechanism) is necessary because total multicast LSP tunnel re-establishment is not efficient in a multicast network. Therefore, this protocol implements a partial multicast LSP tunnel modification mechanism in both the sender- and leaf-initiated mechanisms. Yasukawa, Uga, Kojima, Sugisono [Page 8] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 The features supported by this multicast MPLS protocol are summarized below. The sender-initiated multicast LSP tunnel establishment mechanism has i) multicast LSP tunnel establishment and teardown mechanisms and ii) partial multicast LSP (subtree LSP) tunnel establishment, teardown, and modification mechanisms. This protocol uses an interoperable architecture between the sender- and leaf- initiated multicast LSP tunnel establishment mechanisms, so both mechanisms can modify a multicast LSP tunnel established by either mechanism. +--------+ | Sender | +--------+ Function 1 || | Sender-initiated VV | M-LSP establishment +---+ | A | +---+ | | ^ +---+ +---+ | | | | +---+ +---+ | Function 3 | B | | C | | Leaf initiated +---+ +---+ | M-LSP Join/Leave Function 2 | || || | Sender-initiated | +-++-+ +-++-+ | M-LSP Graft/Prune | | | | | | v V V V V +---++---+ +---++---+ | D || E | | F || G | +---++---+ +---++---+ ^ ^ ^ ^ | | | | +--+ +--+ +--+ +--+ | | | | | | | | +--+ +--+ +--+ +--+ Figure 2: Function supported by this protocol 3.5 Basic operation of multicast LSP tunnels This paragraph explains the basic multicast LSP tunnel establishment mechanism of this protocol, which is an extension of the conventional RSVP-TE protocol. Figure 3 shows the basic sender-initiated multicast LSP tunnel establishment mechanism. Yasukawa, Uga, Kojima, Sugisono [Page 9] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 Path Message (SESSION, SENDER_TEMPLATE, LABEL_REQUEST, TERO, *RRO) Resv Message (SESSION, FILTER_SPEC, LABEL, STYLE, TRRO) Path Path Path -----> -----> -----> . Ingress LSR <----- <----- <----- . (Sender) Resv Resv Resv . +---+ +---+ +---+ +---+ | S |------| N |------| N |------| N |..... +---+ +---+ +---+ +---+ ^| ^| Resv||Path Resv||Path || || |V || Path +---+ || -----> | N |..... || <----- Egress LSR +---+ |V Resv (Leaf) . +---+ +---+ . | N |-----| L | . +---+ +---+ . . . Figure 3: Fundamental Multicast LSP establish mechanism To create a multicast LSP tunnel, the sender node creates an Path message with a TERO in addition to a LABEL_REQUEST object, a SESSION object, and a SENDER_TEMPLATE object. The TERO includes multicast tree information to set. The Path message is forwarded towards its destination along a multicast path specified by the TERO. Each intermediate node along the path records the TERO, SESSION object, and SENDER_TEMPLATE object in its path state block. An intermediate branch node copies the Path message using this TERO information until the destination leaf node is reached. When the Path message reaches the destination leaf node, the leaf node responds to a LABEL_REQUEST by including a LABEL object in its response Resv message. Then the Resv message is sent back upstream toward the sender node, following the path state created by the Path message in reverse order. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this tunnel. If the node is a branch node, it waits for all the Resv massages coming from downstream leaf nodes. After receiving all the Resv messages, it allocates a new label and places it in the corresponding LABEL object of the Resv message, which it sends upstream to the previous hop Yasukawa, Uga, Kojima, Sugisono [Page 10] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 (PHOP). Finally, the merged Resv message propagates upstream to the sender node. Thus, a multicast LSP is established. This label assignment is performed in downstream on-demand mode. 3.6 Multicast session 3.6.1 Multicast session object The SESSION object defined by RSVP-TE is not used for multicasting. To identify a multicast tunnel, MULTICAST_LSP_TUNNEL_IPv4 and MULTICAST_LSP_TUNNEL_IPv6 are added to the SESSION object as new C- Types. They each have a tunnel sender address and Tunnel ID. 3.6.2 MULTICAST_ LSP_TUNNEL_IPv4 session objects Class = SESSION, C-Type = MULTICAST_ LSP_TUNNEL_IPv4 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 tunnel sender address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.6.3 MULTICAST_LSP_TUNNEL_IPv6 session objects Class = SESSION, C-Type = MULTICAST_LSP_TUNNEL_ IPv6 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + + | (16 bytes) | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.7 Explicit routing 3.7.1 Tree Explicit Route Object (TERO) 3.7.1.1 Overview Yasukawa, Uga, Kojima, Sugisono [Page 11] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 Explicit routing is the main function of RSVP-TE. RSVP-TE defines an ERO to show the explicit route. ERO is a list of subobjects. Each subobject represents information about nodes composing the data path. For multicasting, the path topology is a tree. So we extend ERO to express a multicast tree. Therefore, we define a TERO. TERO is included in a message concerning path establishment like the Path message. It specifies nodes of a tree in which the message is traversed. In particular, TERO of a Path message initiated by the sender node contains the whole topology of the multicast tree. Nodes other than message initiators MUST NOT delete the contents of TERO. Each node MAY record the whole topology of the multicast tree from TERO. TERO is also a list of subobjects. Each subobject shows information about a node on the multicast tree. To describe the tree topology, each subobject should be sorted to be able to show link connectivity. For this purpose, the subobjects are arranged in depth-first-order and have a number of hops from the sender node. For the multicast tree shown in the above figure 4, TERO is encoded as follows: A | +----+----+ | | | B I J | | +---+---+ +-+-+ | | | | | C F G K L | | +-+-+ | | | | D E H T={A(0),B(1),C(2),D(3),E(3),F(2),G(2),H(3),I(1),J(1),K(2),L(2)} Figure 4: TERO corresponding to a multicast tree 3.7.1.2 Strict and loose explicit routes Two kinds of explicit route are prepared. In a strict explicit route, the nodes composing the route are specified strictly. A loose explicit route allows an external routing algorithm to decide the route between specified nodes. Multicast routing algorithm such as PIM-SM[8] and MOSPF[9] are examples of such algorithms. These routes are selected at each link of the tree. The protocol allows a mixture of strict and loose explicit routes in the same multicast tree, so Yasukawa, Uga, Kojima, Sugisono [Page 12] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 TERO should show where the strict and loose explicit routes are. The information should relate to nodes described by subobjects. As the information satisfying this condition, the input link status is used to specify strict and loose explicit routes in point-to-multipoint trees. In the case of a multicast point-to-multipoint tunnel, the attribute of an input link relates to each node uniquely. So as the information satisfying this condition, the input link status is used to specify strict and loose explicit routes in a point-to-multipoint tunnel. The L bit in a subobject of TERO shows the input link status of the node. If the L bit shows loose, the input link belongs to a loose explicit route. Otherwise, it belongs to a strict explicit route. This protocol allows the insertion of additional subobjects. In a loose explicit route, the edge nodes of the route indicated as a loose explicit route may know the topology of the network around the loose explicit route. The edge node may calculate the route and specify the route with TERO. In this case, the edge node inserts the calculated route into the TERO of messages related to the loose explicit route. Consider the number of hops from the sender node to a node. It is counted based on the TERO. If intermediate nodes between a leaf node and the sender node belong to a strict explicit route, they are specified in TERO and the leaf node can count the number of hops. When loose explicit routes are part of a multicast tree, the sender node cannot count the number of hops. Because nodes on a loose explicit route are not specified, sender nodes cannot count the number of hops in the loose explicit route. So they cannot calculate the relevant number of hops of the tree nodes. Therefore, the protocol defines the number of hops between the edges of an loose explicit route as 1. This definition satisfies the demand for TERO; using this definition, TERO can show the tree topology and node connectivity. 3.7.1.3 Object format Class = TREE_EXPLICIT_ROUTE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subobject format Yasukawa, Uga, Kojima, Sugisono [Page 13] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 C-Type = IPv4_PREFIX 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type (17) | Length | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Prefix length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Distance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-Type = IPv6_PREFIX 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type (18) | Length | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Prefix length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Tree depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit is an attribute of the subobject. The L bit is set if the route of a path between the node specified by this subobject and its upstream node is not specified (Loose explicit route). If the bit is not set, the route of a path is specified explicitly (Strict explicit route). Type 0x01 IPv4 address 0x02 IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. Yasukawa, Uga, Kojima, Sugisono [Page 14] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 IPv4/6 address An IPv4/6 address of node corresponding to the subobject. In the case that the node has several IP addresses, the address of input interface should be specified. Prefix length Length in bits of the IPv4/6 prefix Distance The distance from sender node to the node specified by the subobject. The value of distance between neighboring nodes specified in TERO is 1. 3.7.2 Tree Record Route Object (TRRO) Record Route Object (RRO) is a list of subobjects describing a node. Each subobject is sorted to show the order in which the message went through the nodes. In multicast communication, some messages SHOULD be merged into a new message to integrate the information that each message conveys. In this case, RRO shows all the nodes through which each message traveled. So RRO should be able to represent the tree structure in multicasting. We call the extended RRO a TRRO. When messages are merged at a branch node, their TRROs also are merged. Each TRRO shows the topology information of the downstream subtree. The merged TRRO is a series of downstream TRROs. The subobject specifying the branch node is inserted at the top of the series. So the merged TRRO shows the subtree whose root is the branch node. In the case of a Resv message, when the message arrives at the root node of the multicast tree related to the Resv message, TRRO shows the current topology of the multicast tree. To represent the tree topology, the subobjects of TRRO are sorted in depth-first-order and they have information about the number of hops from the sender node as the case of TERO. The topology information may be sent to all nodes composing the multicast tree by refreshing the Path message. Yasukawa, Uga, Kojima, Sugisono [Page 15] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 | +----------------------|----------------------+ | Multicast | | | tree T N | | | | | +--------------+--------------+ | | | | | | | +-----------+ +-----------+ +-----------+ | | | Subtree 1 | | Subtree 2 | | Subtree n | | | +-----------+ +-----------+ +-----------+ | +---------------------------------------------+ T = {R(0),T1,T2,...,Tn} Ti = {TRRO describing subtree i} Figure 5 Merged TRRO 3.7.2.1 Object format Class = TREE_EXPLICIT_ROUTE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.7.2.2 Subobject format C-Type = IPv4_PREFIX 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (17) | Length | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Prefix length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree depth | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yasukawa, Uga, Kojima, Sugisono [Page 16] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 C-Type = IPv6_PREFIX 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (18) | Length | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Prefix length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree depth | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x01 IPv4 address 0x02 IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. IPv4/6 address A 32/128-bit unicast, host address. Prefix length 32 Flags 0x01 Local protection available This flag indicates that the link downstream of this node isprotected via a local repair mechanism. 0x02 Local protection in use This flag indicates that a local repair mechanism is used to maintain this tunnel. Yasukawa, Uga, Kojima, Sugisono [Page 17] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 Distance The distance from sender node to the node specified by the subobject. The value of distance between neighboring nodes specified in TERO is 1. 4. Sender-initiated multicast LSP establishment 4.1 Sender-initiated Multicast LSP establishment mechanism The sender node initiates a Path message based on the multicast tree calculation result and establishes the multicast tree using the Path message with TERO. The Path message MUST include SESSION object, LABEL_REQUEST object, SENDER_TEMPLATE and TERO. The sender node sends a Path message to the leaf nodes after initiating it. It is forwarded along the nodes described by TERO and is copied by each branch node. Each node records the information about SESSION object and SENDER_TEMPLATE object as the multicast tree state. If a leaf node receives the Path message, it initiates a Resv message that MUST include SESSION object, FILTER_SPCE and LABEL object and sends it to the sender node. The Resv message is sent back upstream towards the sender node, following the reverse path of the TERO. A LABEL object included in the Resv message is used for label binding. When the sender node receives the Resv messages, the establishment of the multicast LSP is finished. The Resv messages from all leaf nodes should not arrive at the sender node at the same time to enable a large-scale multicast tree to be constructed. So the Resv messages SHOULD be merged at the branch node. Figure 6 shows the sequence of multicast LSP establishment events. Node B, which is the branch node for the nodes C, D, and E, merges the Resv messages. After this merging, the node B initiates a Resv message and sends it upstream. Yasukawa, Uga, Kojima, Sugisono [Page 18] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 +---node--** | (C) +---------node--** | (D) Content | (leaf) Servers--sender--node----------------node---------------node--client (A) (B) (E) (F) | | | | | | | | Path(TERO) | | | | | |----->| | | | | | | | Path(TERO) | | | | | |----->| | | | | | | Path(TERO) | | | | |------------>| | | | | | Path(TERO) | | | | |------------------->| | | | | | | | Path(TERO) | | | | | | |----------------->| | | | | | | Resv(TRRO) | | | | Resv(TRRO) | |<-----------------| | | |<-----| | | | | | | Resv(TRRO) | | | | |<------------| | | | | | |Resv(TRRO) | | | | |<-------------------| | | | Resv(TRRO) | | | | | |<-----| | | | | | | | | | | | | Figure 6 Sequence of sender-initiated multicast LSP establishment events 4.2 Process of sender-initiated multicast LSP establishment A node that receives a Path message refers to the SESSION object and SENDER_TEMPLATE. The node evaluates whether the Path message is a message for first LSP establishment or a refresh message by referring to them. After recording the necessary information in path state block, the node evaluates TERO. The node searches for a subobject whose address is the same as that of the node. If the node detects a subobject in TERO, it gets the address of the next-hop node. Then the node sends a Path message with this address as the destination address. Thus, the destination address of a Path message is a unicast address. If the node is a branch node, it gets multiple addresses of next-hop nodes from TERO. Therefore, the branch node sends multiple Path messages to downstream nodes. Either the intermediate node or the leaf node may calculate the Yasukawa, Uga, Kojima, Sugisono [Page 19] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 multicast tree route in order to decentralize this calculation. So all nodes belonging to the same multicast group need to have information about the whole multicast tree topology in order to prevent intersection of multicast tree. Each node MUST NOT delete the TERO subobjects that specify nodes on the explicitly routed path in order to get the whole multicast tree topology information. Each node MAY record the whole multicast tree topology from TERO. In this way, all nodes can have the same information about the whole multicast tree topology. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender node, it allocates a new label and places that label in the corresponding LABEL object of the Resv message, which it sends upstream to the PHOP. The branch node that sent multiple Path messages forwards Resv messages upstream after receiving those for each Path message. The branch node that sent multiple Path messages to downstream leaf nodes forwards a Resv message upstream only after it receives all the Resv messages from downstream nodes to whom it send a Path message. When Resv messages are merged, a new TRRO is made using TRROs included in the those received Resv messages. This new TRRO expresses the multicast subtree. The branch node that merges Resv message is root node of multicast subtree. The TRRO of the Resv messages is needed to detect loops on the multicast tree. The node SHOULD record information of TRRO. 4.3 Teardown mechanism A multicast LSP tunnel is explicitly torn down by a PathTear message. The PathTear message must be routed exactly like the corresponding Path message. The PathTear message is copied by each branch node and is forwarded downstream to delete the corresponding path state. Prune and Leave messages are defined in this protocol. PathTear messages are initiated not only by the sender node but also by the branch node that receives a Prune or Leave message. The processes of the Prune and Leave messages are described in sections 5.2 and 6.3. 4.4 Path/Resv error During the multicast LSP establishment described in section 4.1 and 4.2, various errors may occur. The main reasons are bandwidth allocation failures and unknown next hops specified by TERO. If a node does not support a new object or new C-type defined by this protocol, it sends error messages indicating "unknown object class" error or an "Unknown object C-Type". A node that initiates a ResvErr message SHOULD send ResvErr messages to all leaf nodes that are affected by the error. Yasukawa, Uga, Kojima, Sugisono [Page 20] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 4.5 Message format 4.5.1 Path message format TERO is added to the Resv message. Note that a new C-Type is added to SESSION object. ::= [ ] [ ] [ ... ] ::= [ ] [ ] 4.5.2 Resv message format TRRO is added to the Resv message. Note that a new C-Type is added to SESSION object. Yasukawa, Uga, Kojima, Sugisono [Page 21] Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002 ::= [ ] [ ] [ ] [ ... ]