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)
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.
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
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.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<TREE_EXPLICIT_ROUTE>
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
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
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION><RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <TREE_RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC>
<LABEL>[ <TREE_RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <TREE_RECORD_ROUTE> ]
4.5.3 PathTear message format
Note that a new C-Type is added to SESSION object.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
4.5.4 PathErr message format
Note that a new C-Type is added to SESSION object.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
< SESSION >
<ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
4.5.5 ResvErr Message format
Yasukawa, Uga, Kojima, Sugisono [Page 22]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
Note that a new C-Type is added to SESSION object.
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
< SESSION > <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE>[<error flow descriptor>]
5. Sender-initiated grafting/pruning mechanism
5.1 Sender-initiated grafting mechanism
The grafting mechanism supports to graft a partial multicast tree
(subtree) onto an established multicast tree. It allows an
intermediate node to graft (add) a subtree in order to scale up the
performance of the grafting process. We define the node that performs
subtree establishment as a graft node. The sender node sends a Graft
message that includes partial multicast information to the graft
node. The intermediate node placed between the sender node and this
graft node SHOULD NOT process this Graft message and SHOULD only
relay it to the graft node. The graft node that receives this message
MUST extract TERO information from it and perform a partial multicast
grafting process by sending a Path message and receiving a Resv
message. This grafting process is initiated not only by the sender
node but also by the NMS.
Yasukawa, Uga, Kojima, Sugisono [Page 23]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
+----node--**
| (C)
+-----------node--** +---------node-----client
| (D) | (F)
Content | | (Leaf)
Servers--Sender--node----------------node---------------node--client
(A) (B) (E) (G)
| | | | | | | |
| | Graft(TERO) | | | | |
|-------------------------->| | | |
| | | | | Path(TERO) | |
| | | | |----------------->| |
| | | | | Path(TERO) | |
| | | | |---------->| | |
| | | | | Resv(TRRO) | |
| | | | |<-----------------| |
| | | | | Resv(TRRO) | |
| | GraftNotify(TRRO) |<----------| | |
|<------------ <------------| | | |
| | | | | | | |
Figure 7: Sequence of graft process
Figure 7 shows the message sequence of the proposed grafting process.
Sender node A sends a graft message to graft node E to establish a
subtree tunnel from node E. Graft node E gets grafting tree
information by extracting TERO information from the Graft message.
Then graft node E sends Path messages that include the same TERO
object to set up an expanded tree. In this example, graft node E
sends Path messages to leaf nodes F and G. After confirming the
establishment of the expanded tree by receiving Resv messages, the
graft node MUST send a GraftNotify message to the sender node to
report the result of the grafting process. The GraftNotify message
carries expanded tree tunnel information by including a TRRO that
collects individual tree setup information carried by the Resv
messages. The GraftNotify message SHOULD NOT be processed and SHOULD
only be relayed by the intermediate node placed between the graft
node and sender node.
Figure 8 shows the error message sequence of the grafting process. In
this example, part of the expanded tree tunnel cannot be established
for some reason, such as a resource error or label assignment error.
Each node that cannot establish an LSP SHOULD send a PathErr message
that includes the error code to the graft node. The graft node that
receives these PathErr messages SHOULD extract the error codes and
collect this information into a GraftErr message and SHOULD send this
message to the graft initiator (sender node).
Yasukawa, Uga, Kojima, Sugisono [Page 24]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
+----node--** +----node-----client
| (C) | (H)
+----------node--** +-----------node-----client
| (D) | (G)
Content | | (Leaf)
Servers--Sender--node---------------node-----------------node--client
(A) (B) (E) (F)
| | | | | | | | |
| | Graft(TERO) | | | | | |
|-------------------------->| | | | |
| | | | |Path(TERO) | | |
| | | | |------------------->| |
| | | | |Path(TERO) | | |
| | | | |------------>| | |
| | | | |Path(TERO) | | |
| | | | |----->| | | |
| | | | | | Resv(TRRO) | |
| | | | |<-------------------| |
| | | | | PathErr | | |
| | | | |<------------| | |
| | | | | PathErr | | |
| | GraftNotify(TRRO) |<-----| | | |
|<------------ <------------| | | | |
| | GraftErr | | | | | |
|<--------------------------| | | | |
| | | | | | | | |
| | | | | | | | |
Figure 8: Sequence of graft error process
When a node requested to perform the grafting process does not
support this mechanism, this node SHOULD send an error message
including the unknown class object to inform the graft initiator
(sender node) of the lack of support for this mechanism. When a graft
node that is requested to perform a grafting process detects some
error in this message, it SHOULD send a GraftErr message that
includes the error code to the graft initiator (sender node). The
following are examples of errors. One example is where a requested
expanded multicast tree tunnel already exists below the graft node.
The other example is that establishment of requested subtree tunnel
is impossible in principle because TERO shows nodes that do not
exist.
Graft, GraftNotify, and GraftErr messages are introduced for the
graft process. The Graft message is utilized to expand a subtree
tunnel at a graft node. This message has the following format. It
MUST include a SESSION object and SENDER_TEMPLATE object to specify
the target multicast session. And it MUST include a TERO to describe
Yasukawa, Uga, Kojima, Sugisono [Page 25]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
the expanded multicast tree tunnel information.
<Graft Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION > <RSVP_HOP>
<TIME_VALUES>
<TREE_EXPLICIT_ROUTE>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <see earlier definition>
The GraftNotify message is utilized by the graft node to notify the
graft initiator (sender node) of the results of the grafting process.
This message MUST include a TRRO to describe the expanded multicast
tree tunnel information.
<GraftNotify Message> ::= <Common Header> [ <INTEGRITY> ]
< SESSION > <RSVP_HOP>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= < see earlier definition>
The GraftErr message is utilized by the graft node to explain the
reason for the error to the graft initiator. The GraftErr message
shows the converged error information carried by PathErr messages
that is addressed to the graft node. This message has the following
format. Error information is carried by the ERROR_SPEC object.
<GraftErr Message>::=<Common Header>[<INTEGRITY>]
< SESSION ><ERROR_SPEC>
[<POLICY_DATA>....]
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
5.2 Sender-initiated pruning mechanism
The pruning mechanism supports prune unnecessary multicast subtree
tunnels from an established multicast tree tunnel. It allows an
intermediate node to prune unnecessary multicast subtree tunnels. We
define the node that performs the pruning as a prune node. The sender
node sends a Prune message that includes information about
unnecessary multicast subtrees to prune node. The node placed between
the sender node and this prune node SHOULD NOT process this message
and SHOULD only relay it to the prune node. The prune node that
Yasukawa, Uga, Kojima, Sugisono [Page 26]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
receives this message MUST extract TERO information from it and MUST
prune unnecessary multicast subtree tunnels by sending PathTear
messages. This pruning process is initiated not only by the sender
node but also by NMS.
+----node--** +----node-----client
| (C) | (H)
+-----------node--** +-----------node----client
| (D) | (G)
Content | | (Leaf)
Servers--Sender--node----------------node----------------node--client
(A) (B) (E) (F)
| | Prune(TERO) | | | | | |
|-------------------------->| | | | |
| | | | |Path Tear | | |
| | | | |------------------->| |
| | | | |Path Tear | | |
| | | | |------------>| | |
| | | | |Path Tear | | |
| PruneNotify | |----->| | | |
|<--------------------------| | | | |
| | | | | | | | |
Figure 9: Sequence of graft prune process
Figure 9 shows the message sequence of the pruning process. Sender
node A sends a Prune message to Prune node E to prune an unnecessary
multicast subtree tunnel from node E. Prune node E gets the
information about unnecessary the multicast subtree tunnel by
extracting TERO information from the Prune message. In this example,
graft node E sends PathTear messages to leaf nodes F, G, and H. After
it has sent all the PathTear messages, the prune node MUST send a
PruneNotify message to the sender node to report the accomplishment
of pruning process. The PruneNotify message SHOULD NOT be processed
and SHOULD only be relayed by the intermediate node placed between
the prune node and sender node.
When a node requested to perform pruning does not support this
mechanism, this node SHOULD send an error including the unknown class
object to notify the prune initiator (sender node) of the lack of
support for this mechanism. When a prune node requested to perform
pruning detects some error in this message, it SHOULD send a PruneErr
message that includes the error reason code to the prune initiator
(sender node). The following are examples of errors. One example is
where the specified unnecessary multicast subtree tunnel has already
been deleted under the pruning node. The other example is that
pruning of the unnecessary multicast subtree tunnel is impossible in
principle because TERO shows non-existing nodes.
Yasukawa, Uga, Kojima, Sugisono [Page 27]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
Prune, PruneNotify, and PruneErr message are introduced to achieve
the pruning process.
The Prune message is utilized to prune an unnecessary multicast
subtree tunnel at a prune node. This message has the following
format. It MUST include a SESSION object and SENDER_TEMPLATE to
specify the target multicast LSP tunnel Prune. And it MUST include a
TERO to describe unnecessary multicast subtree tunnel information.
<Prune Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION > <RSVP_HOP>
<TREE_EXPLICIT_ROUTE>
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
The PruneNotify message is utilized by the prune node to notify the
prune initiator (sender node) of the results of the pruning process.
<PruneNotify Message> ::= <Common Header> [ <INTEGRITY> ]
< SESSION > <RSVP_HOP>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <see earlier definition>
The PruneErr message is utilized by the prune node to explain the
reason for the error to the Prune initiator. It MUST include
converged error information. This message has the following format.
Error information is carried by the ERROR_SPEC object.
<Prune Err Message>::=<Common Header>[<INTEGRITY>]
< SESSION ><ERROR_SPEC>
[<POLICY_DATA>....]
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
6. Leaf-initiated multicast LSP establishment
6.1 Leaf-initiated joining mechanism
When a node would like to join a multicast group, it sends Join
message corresponding to the group. Here, we call the node a join
leaf node. A Join message is a trigger for establishing a QoS path
requested by a join leaf node. The node expanding a new path to a
Yasukawa, Uga, Kojima, Sugisono [Page 28]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
join leaf node is called a graft node, as in the case of grafting.
Two types of node can be the destination of a Join message. One is
the sender node of the multicast tree. In this case, the graft node
is the cross point of the multicast tree and the reverse path from
the join leaf node; it is the nearest one to the join leaf node. The
other is a node indicated by a Explicit Route object in the Join
message. In this case, the graft node is the indicated node. The
route of the expanded path is the same one through which the Join
message traveled. The nodes that a Join message goes through are
recorded in the RRO of the message. Therefore, nodes can detect a
path loop from the RRO of the Join message. A Join message has no
specifications about the QoS parameters of the expanded path. These
parameters are included in the Path/Resv message used for path
establishment.
The process of expanded path establishment is as follows. The leaf
node joining a multicast group sends a Join message to the sender
node or graft node.
First, we describe the case where the destination of the message is a
sender node. The join leaf node sends a Join message through the path
that connects to the sender node of the multicast session. The join
leaf node MUST put tunnel information in the SESSION and
SENDER_TEMPLATE objects of the Join message. To resolve the tunnel
ID, LS` ID and tunnel sender address the join leaf node queries the
NMS located in the network. The route of the path is either decided
by an external routing protocol or is the shortest path between the
sender node and join leaf node. As soon as it receives the message, a
node on the message's forwarding path checks whether it has tunnel
information specified by the message. If there is tunnel information
identified by the message, the node becomes a graft node.
Next, we describe the case where the graft node is not the sender
node of the tree. The Join message is forwarded to the specified
graft node. After the graft node receives the message, it checks the
path state block and searches the entry about the tunnel. If it
cannot find the entry, it sends a JoinErr message to the join leaf
node. The JoinErr message is defined in the next section. Otherwise,
it becomes the graft node. The graft node is responsible for
expanding the QoS path to the Join group. It sends a Path message to
allocate the bandwidth of the expanded path. The route of the
expanding path is decided by the graft node or join leaf node or NMS.
If the join leaf node specifies the route, the specified route is
recorded in the ERO of the Join message. The bandwidth allocation
finishes when the graft node receives a Resv message from the join
leaf node. The QoS parameters for the expanded path are specified in
the Path/Resv message.
Yasukawa, Uga, Kojima, Sugisono [Page 29]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
After the bandwidth allocation, the graft node notifies the sender
node of the multicast tree of the establishment of the QoS path in a
JoinNotify message. This message SHOULD NOT be processed at any
intermediate nodes. The message is a trigger for changing the
topology information of all the nodes. The information MAY be
traversed to all nodes composing the multicast tree by the Path
refresh process.
:
:
+---......
Content | (leaf)
Servers--Sender--node-----------------node-----------------node--client
(A) (E) (F) Join (G)
| Join |<-------------------| |
|<--------------------| | |
| Path | | |
|-------------------->| Path | |
| |------------------->| |
| | Resv | |
| Resv |<-------------------| |
JoinNotify |<--------------------| | |
<---------------| | | |
| | | |
| | | |
Figure 10: Sequence of join process
6.2 Join Error
During the Join process described in the previous section, various
errors may occur. In the Join process, the join leaf node is notified
of the errors and analyzes them. There are many methods for the join
leaf node to collect the information about errors. For this purpose,
we define a JoinErr message, which is sent by the graft node to the
join leaf node. It is made when the graft node receives a PathErr
message, which notifies the Path message initiator (in this case, the
graft node) (Figure 11).
Yasukawa, Uga, Kojima, Sugisono [Page 30]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
:
:
+---......
Content | (leaf)
Servers--Sender--node----------------node------------------node--client
(A) (E) (F) Join (G)
| Join |<-------------------| |
|<-------------------| | |
| Path | | |
|------------------->| | |
| PathErr | | |
|<-------------------| | |
| JoinErr | | |
|--------------------|------------------->| |
Figure 11: Sequence of JoinErr process
6.3 Leave-initiated leaving mechanism
A leaf node that wants to leave a multicast group sends a Leave
message to request the tearing down of a path. We call such a leaf
node a leave leaf node. In this case, the path from the leave leaf
node to its nearest upstream branch node is torn down. The branch
node is called a prune node and it is responsible for tearing down
the QoS path connecting to the leave leaf node. The leave leaf node
sends a Leave message to the sender node. The prune node receives the
message and processes it. Intermediate nodes below the prune node
forward the Leave message upstream. It SHOULD NOT be processed at any
intermediate nodes.
To be a prune node, a node must be a branch node. A branch node has
two or more downstream paths. Nodes in a network have the information
of the number of downstream paths for a multicast group. So the node
receiving a Leave message checks the number of downstream links and
decides whether it is a prune node or not.
As soon as it receives the message, the prune node tears down the
unnecessary path. In the path tearing process, a PathTear message is
used. When the leave leaf node receives a PathTear message, it
recognizes the completion of path tearing.
Yasukawa, Uga, Kojima, Sugisono [Page 31]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
:
:
+---......
Content | (leaf)
Servers--Sender--node-----------------node----------------node--client
(A) (E) (F) Leave (G)
| Leave |<-------------------| |
|<-------------------| | |
| PathTear | | |
|------------------->| PathTear | |
LeaveNotify | |------------------->| |
<---------------| | | |
| | | |
| | | |
Figure 12: Sequence of leave process
6.4 Message format
6.4.1 Join message format
<Join Message>::=<Common Header>[<INTEGRITY>]
<SESSION ><RSVP_HOP>
[<SCOPE>]<TIME_VALUES>
[<EXPLICIT_ROUTE>]
[<sender descriptor>]
<sender descriptor>::=(see earlier definition)
ERO contains the route on which the message is sent. It is a list of
subobjects showing node information. The route specified by the
object is calculated at leaf node or NMS. This information is used
for deciding the route of the Path message sent by the graft node.
6.4.2 JoinNotify message format
<JoinNotify Message>::=<Common Header>[<INTEGRITY>]
<SESSION><RSVP_HOP>
[<SCOPE>]
[<flow descriptor>]
<flow descriptor>::=(see earlier definition)
Yasukawa, Uga, Kojima, Sugisono [Page 32]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
6.4.3 JoinErr message format
<JoinErr Message>::=<Common Header>[<INTEGRITY>]
< SESSION ><ERROR_SPEC>
[<SCOPE>]
[<POLICY_DATA>....]
<sender descriptor>
<sender descriptor>::=(see earlier definition)
The ERROR_SPEC object contains the information about the errors. The
contents are the location and reason of the error reported by a
PathErr message.
6.4.4 Leave message format
<Leave Message>::=<Common Header>[<INTEGRITY>]
< SESSION ><RSVP_HOP>
[<SCOPE>]
[< sender descriptor >]
< sender descriptor >::=(see earlier definition)
6.4.5 LeaveNotify Message
<LeaveNotify Message> ::= <Common Header> [ <INTEGRITY> ]
< SESSION > <RSVP_HOP>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <see earlier definition>
7. Multi-point to multi-point multicasting
7.1 MPLS Rendezvous Point (MRP)
Supporting multipoint-to-multipoint traffic is important for
multicast communication. An example of multipoint-to-multipoint
traffic is a video conference.
This protocol supports multipoint-to-multipoint LSP tunnels. An MPLS
Rendezvous Point (MRP) is defined. This is similar to the rendezvous
point of PIM-SM. The MRP receives traffic from the sender node and
forwards it to the shared multicast tree. MRP binds multiple unicast
LSPs and a multicast LSP. This binding means i) to specify the
multicast LSP to bind, ii) to bind new input labels and existing
output labels, iii) to swap them, and iv) to forward from multiple
Yasukawa, Uga, Kojima, Sugisono [Page 33]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
sender nodes to multiple leaf nodes. Because the MRP relates i)
multiple unicast LSPs from the sender nodes to the MRP to ii) a
multicast LSP from the MRP to the leaf nodes, this protocol can
support multipoint-to-multipoint LSPs. Figure 13 shows a multipoint-
to-multipoint LSP tunnel. It shows two unicast LSPs from sender node
A and B to MRP and one multicast LSP from MRP to the leaf nodes D, F,
and I. If a packet has Label A or B, MRP copies this packet to make
three packets and assigns Label C, E, and G to these packets.
+------+ +------+
/ Node / / Node /
/ (C) /----/ (D) /
+------+ +------+
^ |
Label C| |
| |
| |
+-------+ +------+ Label A +-----+ Label E +------+ +------+
/Content/ /sender/--------->/ MRP /-------->/ Node / / Node /
/Servers/----/ (A) /----------/ /---------/ (E) /--/ (F) /
+-------+ +------+ +-->+-----+ +------+ +------+
/ / | |
Label B/ / | |Label G
/ / | v
+-------+ +------+ / +------+ +------+ +--------+
/Content/ /sender/ / / Node / / Node / / Node /
/Servers/----/ (B) /----+ / (G) /-----/ (H) /--/ (I) /
+-------+ +------+ +------+ +------+ +--------+
Figure 13: Multipoint-to-multipoint LSP tunnel
7.2 Add mechanism
An Add message is defined as a new message. It establishes a unicast
LSP from the sender node to the MRP. Moreover, an Add message reports
to the MRP that a new sender node has been added.
Multiple unicast LSPs from the sender nodes to the MRP and a
multicast LSP from the MRP to the leaf nodes are treated as different
LSPs. The Tunnel ID and LSP ID of the unicast LSP have different
values from those of the multicast LSP. The MRP relates the Tunnel ID
and LSP ID of the unicast LSP to those of the multicast LSP. The MRP
keeps the multipoint-to-multipoint state by this relationship.
An Add message must specify the multicast LSP to bind. To identify a
multicast LSP to bind, BIND_SESSION object and BIND_SENDER_TEMPLATE
are defined. BIND_SESSION class and BIND_SENDER_TEMPLATE class are
added. BIND_SESSION object has the same format as SESSION object.
Yasukawa, Uga, Kojima, Sugisono [Page 34]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
BIND_SENDER_TEMPLATE has the same format as SENDER_TEMPLATE.
+----node--**
| (C)
+-----------node--**
Content | (D) (leaf)
Servers--Sender-----MRP-----------------node------------node--client
(A) (E) (F)
| Add | | | | | |
|---------->| Path | | | | |
| |----->| | | | |
| | Path | | | |
| |------------>| | | |
| | Path | | | |
| |------------------->| Path | |
| | | | |-------------->| |
| | Resv | | Resv | |
| |<-----| | |<--------------| |
| | Resv | | | |
| |<------------| | | |
| | Resv | | | |
| Resv |<-------------------| | |
|<----------| | | | | |
| Path | | | | | |
|---------->| | | | | |
| | | | | | |
Figure 14: Sequence of Add process
7.3 Add message format
Though the Add message is similar to the Path message, it has two
additional functions: i) to notify the MRP that a new sender node has
been added and ii) to identify a binding multicast LSP.
Yasukawa, Uga, Kojima, Sugisono [Page 35]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
<Add Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION><BIND_SESSION>
<RSVP_HOP>
<TIME_VALUES>
[<TREE_EXPLICIT_ROUTE>]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<BIND_SENDER_TEMPLATE>
<sender descriptor> ::= (see earlier definition)
8. Application for Traffic Engineering
8.1 Rerouting Traffic Engineered Multicast Tunnels
Traffic Engineering supports rerouting of an established TE tunnel.
The route is decided according to the administrative policy. The
detection of a more optimal path and network resource failure are
examples of situations where path rerouting is needed.
While TE tunnel rerouting is in progress, an important requirement is
avoiding traffic disruption. A useful solution to this problem is the
make-before-break concept. In this concept, traffic passes through
the old path while the new rerouted path is being established. Once
it has been established, traffic is switched to the new path and the
old path is torn down. The make-before-break concept supports
resource sharing of the common part where the old and new path cross.
This sharing is useful to avoid competition between the resources of
the two paths. Details of the make-before-break concept are given in
RFC 3209. In the case of multicasting, there are cases where the
topology of the area to be rerouted is a tree and there are many
paths that should be rerouted when path rerouting occurs at once. So
it is desirable that multiple paths are moved in one rerouting
mechanism.
This protocol supports the make-before-break concept for multicast TE
tunnels. When a sender of a multicast reroutes part of the multicast
tree, the sender sends Path messages. Each message has route
information about a new partial tree in its TERO. While the new path
is being established, the root of the paths refreshes Path/Resv
messages for the new partial tree to be established and the old
partial tree to be rerouted. After completion of the new path, the
initiator specifies the route of the old partial tree in the TERO of
a PathTear message and sends the message to the old rerouted partial
tree. The network resource sharing is achieved by the Shared Explicit
reservation style as in the unicast make-before-break concept. So
Yasukawa, Uga, Kojima, Sugisono [Page 36]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
this protocol helps to extend the make-before-break concept to
multicast TE tunnels.
8.2 Re-establishment of subtree
A Graft message can also be used re-establish a partial multicast LSP
when the establishment of the sub-tree failed. In multicast LSP
establishment, it sometimes happens that the establishment of the
sub-tree fails and the establishment of another part of the tree
succeeds. It is inefficient in this situation for the whole multicast
LSP to be torn down by the PathTear message and for the whole
multicast LSP to be re-established by the Path message. Re-
establishment of a sub-tree whose establishment failed can be done
using the Graft message. The sender node or NMS that recognizes that
the establishment of a sub-tree failed can re-calculate another
multicast route that avoids the failure point and can reach the leaf
nodes. After this re-calculation, the sender node sends a Graft
message with TERO for sub-tree re-establishment. This re-
establishment does not cause any additional processing in nodes
except for this failure point, because the Graft process only needs
additional processes in the failure point. An LSP tunnel can be
expanded by the Graft message defined by this protocol. So this
protocol can establish LSP tunnels easily and flexibly, even if sub-
tree establishment fails.
9. Security Considerations
Security considerations will be addressed in a future revision of
this document.
10. References
[1] D. Awduche., L. Berger., D. Gan., T. Li., V. Srinivasan.,
G. Swallow "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001
[2] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[3] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Yasukawa, Uga, Kojima, Sugisono [Page 37]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
Levels", BCP 14, RFC 2119, March 1997.
[6] W. Fenner, "Internet Group Management Protocol, IGMP, version
2", RFC 2236, November 1997.
[7] Cain, B., "Internet Group Management Protocol, Version
3", draft-ietf-idmr-igmp-v3-11.txt, May 2002
[8] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering,
M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification.", RFC 2362, June 1998.
[9] J. Moy., "Multicast Extensions to OSPF", RFC 1584, March 1994
[10] Lou Berger., et al. "Generalized MPLS - Signaling Functional
Description" , draft-ietf-mpls-generalized-signaling-08.txt ,
April 2002
Author's Address
Seisho Yasukawa
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769
EMail: yasukawa.seisho@lab.ntt.co.jp
Masanori Uga
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4804
EMail: uga.masanori@lab.ntt.co.jp
Hisashi Kojima
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6070
Yasukawa, Uga, Kojima, Sugisono [Page 38]
Internet Draft draft-yasukawa-mpls-rsvp-multicast-00.txt June 2002
EMail: kojima.hisashi@lab.ntt.co.jp
Koji Sugisono
NTT Network Service Systems Laboratories, NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 2605
EMail: sugisono.koji@lab.ntt.co.jp
Yasukawa, Uga, Kojima, Sugisono [Page 39]