Internet DRAFT - draft-choi-mpls-grouplabel
draft-choi-mpls-grouplabel
Internet Draft Jun Kyun Choi
Document: draft-choi-mpls-grouplabel-00.txt ICU
Expiration Date: August 2003 Sun Hee Yang
ETRI
Hyoung Jun Kim
ETRI
Ki Shik Park
ETRI
Min Suk Sung
ICU
March 2003
Group label allocation mechanism in MPLS networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026.
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 obsolete by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
As the group communication become more important, the special label
should be allocated in support of group management and maintenance.
The allocation mechanism of group label can be applied to a point-to-
multipoint communication in MPLS networks. Currently used label is
locally significant, while this special label should be common object
within a single MPLS domain. This document specifies the allocation
mechanism of group label in order to perform unidirectional point-to-
multipoint communication.
Conventions
Choi, et. al. Expires August 2003 [Page 1]
Group label allocation mechanism in MPLS network March 2003
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 RFC-2119.
Table of Contents
1. Introduction.....................................................3
2. Related works....................................................3
3. Applicability....................................................3
4. Architecture.....................................................4
4.1 Point-to-multipoint communication based on client-server model..4
4.1.1 Replication function..........................................4
4.1.2 Merging function..............................................5
4.1.3 Neighbor information base (NIB)...............................5
4.2 Point-to-multipoint communication based on peer model...........5
4.3 Unidirectional point-to-multipoint communication mechanism......6
4.3.1 Procedures for setting up unidirectional point-to-multipoint
communication.......................................................6
4.3.2 Joining mechanism.............................................7
4.3.3 Leaving mechanism.............................................8
5. Required message format..........................................8
5.1 Path message....................................................8
5.2 Resv message....................................................9
6. Extended Object format...........................................9
6.1 Hello object for group management...............................9
6.2 Group label object.............................................10
6.3 Group label request object.....................................10
7. Other issues....................................................11
8. Security considerations.........................................11
9. References......................................................12
10. Author's Addresses.............................................13
Choi, et. al. Expires August 2003 [Page 2]
Group label allocation mechanism in MPLS network March 2003
1. Introduction
It is increasingly important to guarantee real-time application
requiring more strict QoS and higher bandwidth such as Internet
broadcasting, video conferencing and real-time delivery services,
therefore the group communication will become very useful for these
purposes. The special label should be allocated in support of group
management and maintenance. The allocation mechanism of group label
can be applied to a point-to-multipoint communication.
Currently a variety of research is actively performed to support
point-to-multipoint communication focusing on RSVP-TE[4] or CR-LDP[5]
in MPLS networks and group label allocation also can be a scheme for
configuring MPLS networks.
The group label is a common object to establish and maintain the
point-to-multipoint connection within a single MPLS domain. We can
discuss only unidirectional communication which means that only a
single sender creates group label request object requiring a group
label. The group label allocation for bidirectional communication is
a subject for future study, which means that several LSRs also create
group label request objects and send them to a single node.
2. Related works
- RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels"
This RFC describes the extension of RSVP for establishing traffic
engineered path. The proposed mechanism for resource reservation
is intended for group communication.
- RFC 3353, "Framework for IP Multicast in MPLS"
This RFC introduces the extended IP multicast mechanism for L2. It
proposes to establish the point-to-multipoint LSP using L3
multicasting rouging protocol. This mechanism addresses the
concept of group management and the common object identifying
among groups.
- RFC 3212, "Constraint-Based LSP using LDP"
This RFC describes the procedure for establishing traffic
engineered path using extended LDP signaling. The proposed
mechanism is intended for configuring and negotiating traffic
parameters.
3. Applicability
This document is considered as a group label allocation which defines
the multicasting support in MPLS networks. Instead of local
significant concept of a label, the common group label with a single
MPLS network is allocated to support point-to-multipoint
Choi, et. al. Expires August 2003 [Page 3]
Group label allocation mechanism in MPLS network March 2003
communication so that interactive broadcasting and Video on demand
service can be provided.
In view of expenditure and maintenance, it is difficult to realize
the multicasting with a group label including server application in
backbone MPLS network, while access MPLS network may provide high
capacity services such as content delivery, preserving network
infrastructure.
The globally unique server which manages local servers every MPLS
domain will be applicable in the future. So, the enhancement for the
point-to-multipoint technology will be gradually achieved from access
to backbone MPLS network.
4. Architecture
4.1 Point-to-multipoint communication based on client-server model
A single Server is equipped with the concept of multipoint control
unit (MCU) which can enable two or more receivers to intercommunicate
with a single sender like conferencing. So, the point-to-multipoint
connection can be established using a single server locally. This
server has two functions; one is a merging function for Path message
with group label request object and the other is a replication
function for Resv message with group label.
It is totally reliable and robust to establish this communication
because a server manages the traffic engineered explicit routes to
avoid link failure before forwarding a Path message from a sender.
4.1.1 Replication function
A Replication function point in the MPLS network is a point in a
point-to-multipoint connection where Path message with group label
request from one incoming path is replicated on two or more outgoing
paths. In MPLS network, a replication function is based on the group
label request object. At the replication point each group label
request is copied onto two or more outgoing paths. The server checks
whether a explicit route is traffic-engineered and then forwards Path
message to those routes. If explicit routes are negotiable, server
node allocates the Path message with group label request for them,
otherwise they cannot be involved in the point-to-multipoint
connection.
. . .
+---+
+--------->| B |
+---+ +---+ | +---+
| A |------------>| S |----+
+---+ +---+ | +---+
+--------->| C |
+---+
Choi, et. al. Expires August 2003 [Page 4]
Group label allocation mechanism in MPLS network March 2003
S = server node . . .
Figure 1. Replication function
4.1.2 Merging function
A Merging Function point in the MPLS network is a point in a point-
to-multipoint connection where Resv messages with group label from
two or more paths are combined in a single path. In this document,
merging function exists in only Resv message since unidirectional
point-to-multipoint connection is just supported.
. . .
+---+
+--<---------| B |
+---+ +---+ / +---+
| A |<------------| S |+
+---+ +---+ | +---+
+--<---------| C |
+---+
S = server node . . .
Figure 2. Merging function
4.1.3 Neighbor information base (NIB)
The server contains this database which has IPv4 address/IPv6 address
and explicit routes of all LSRs within a single MPLS domain. All of
the LSRs in a single MPLS domain periodically sends hello message to
the server, therefore the server can maintain and update the
information of all LSRs within a MPLS domain. The server use this
information to handle a group label request received from a sender.
4.2 Point-to-multipoint communication based on peer model
This model doesn't need any server and hello message for group
management because a LSR which wants to establish point-to-multipoint
connection can directly send Path message containing group label
request to all of the LSRs within a MPLS domain. A LSR which sends
Path message doesn't know who will receive. All of the LSRs which
received Path message determine whether to join a point-to-multipoint
connection. If they accept the request, they send Resv message with
group label. Otherwise, they ignore the request. After receiving Resv
messages from LSRs, the point-to-multipoint connection between a
single sender and multiple receivers can be established within a MPLS
domain. The common group label should be used in this communication.
In peer model, there are much smaller overhead for messages and
maintaining a server with a huge database. On the other hand, the
failing possibility to establish a point-to-multipoint connection is
much higher than the client-server model, since a server which
chooses traffic engineered explicit route between a sender and
receivers doesn't exist.
Choi, et. al. Expires August 2003 [Page 5]
Group label allocation mechanism in MPLS network March 2003
4.3 Unidirectional point-to-multipoint communication mechanism
4.3.1 Procedures for setting up unidirectional point-to-multipoint
communication
All of the LSRs within a single MPLS domain can be a sender or
receiver. If a sender node is designated, rest of them becomes
receivers. There exists a server per MPLS domain. The following is
the procedures of setting up unidirectional point-to-multipoint
communication.
1. All of the LSRS within a single MPLS domain send hello message to
a server so that the server can register each IP address and
explicit route of each LSR to the NIB. The server has the NIB
including IP address and explicit route. So, the server maintains
the NIB due to periodical transmission of a hello message.
2. If a single LSR sends the Path message containing group label
request to a server, all of the LSRs except for a sender become
receivers within a MPLS domain.
3. After choosing explicit routes registered in NIB, the server
copies group label request as the number of chosen explicit route
and sends the Path message including group label request.
4. Among nodes receiving the Path message containing group label
requet, the node which is ready to accept the group label request
and join the point-to-multipoint communication allocates group
label to the Resv message.
5. The server received several Resv messages containing group label
performs the merging function. Then, the server creates and send
new Resv message containing group label to a sender.
6. After distributing the Resv message from multiple receiver to a
sender, the point-to-multipoint LSP is established and starts
point-to-multipoint communication, which a single sender and two
or more receivers are sharing the common group label.
+------------------------------------------+
| Hello |
| <------ |
| +--------B |
| Hello +-----+ | |
| -------> | |<---+--------C |
| A--------->| S | |
| | |<---+--------D |
| +-----+ | |
| +--------E |
| <------- |
| single MPLS domain Hello |
Choi, et. al. Expires August 2003 [Page 6]
Group label allocation mechanism in MPLS network March 2003
+------------------------------------------+
Path
--------->
+----------------B
| <---------
| Resv
|
|
Path | Path
--------> +---+ --------->
A--------------| S |--------------C
<-------- +---+ <---------
Resv | Resv
|
|
| Path
| --------->
+----------------D
<---------
Resv
Figure 3. Set up for a point-to-multipoint connection
4.3.2 Joining mechanism
After establishing point-to-multipoint communication, the following
mechanism is applied when a new LSR intends to join this group.
- a new LSR sends a join message to a server.
- The server stores the information extracted from a Join message in
NIB and then forwards the join message to the sender.
- The sender received the join message sends a Path message
containing group label request to the server.
- The server received the Path message sends it to the new LSR if
being traffic-negotiable about explicit route.
Otherwise, the server sends notification message to the sender and
teardown message to the new LSR.
- The new LSR received the Path message sends Resv message to a
server.
- Then, the server forwards it to the sender and the new LSR can
join the point-to-multipoint communication.
The procedure of joining mechanism is illustrated in Figure 4.
+--------------------------B
| |
| . |
| . |
+---+ . |
A--------------| S |--------------C |
| +---+ |
Choi, et. al. Expires August 2003 [Page 7]
Group label allocation mechanism in MPLS network March 2003
| Join | Join |
|<--------------|<-----------------------|
| | |
| Path | Path |
|-------------->|----------------------->|
| | |
| Resv | Resv |
|<--------------|<-----------------------|
| | |
Figure 4. Joining mechanism
4.3.3 Leaving mechanism
Among LSRs joining the point-to-multipoint communication, the LSR
which intends to tear down the connection sends a leave message to a
server. The server sends a notification message to the sender and a
teardown message to the LSR which requests to leave.
The procedure of leaving mechanism is illustrated in Figure 5.
+--------------------------B
| |
| . |
| . |
+---+ . |
A--------------| S |---------------C |
| +---+ |
| | Leave |
| Notification |<-----------------------|
|<--------------| |
| | |
| | teardown |
| |----------------------->|
| | |
Figure 5. Leaving mechanism
5. Required message format
5.1 Path message
In case a single LSR within a MPLS domain creates a Path message with
label request which requires allocating group label and sends to the
server, the rest of LSRS becomes receivers. The server sends Path
message along the explicit routes registered in NIB. The modified
message is shown in Figure 6.
<path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <REVP-HOP>
<TIME-VALUE>
<GROUP-LABEL-REQUEST>
[ <SESSION-ATTRIBUTE> ]
Choi, et. al. Expires August 2003 [Page 8]
Group label allocation mechanism in MPLS network March 2003
[ <POLICY-DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER-TEMPLATE> <SENDER-TSPEC>
Figure 6. Path message
5.2 Resv message
LSRs received path message from server allocate a group label as a
part of Resv message and is sent through the server to the sender
along the reverse path of Path message. The modified format of Resv
message is as follows in Figure 7.
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP-HOP>
<TIME-VALUE>
[ <RESV-CONFIRM> ] [ <SCOPE> ]
[ <POLICY-DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor list>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER-SPEC>
<GROUP-LABEL> [ <RECORD-ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER-SPEC>
<GROUP-LABEL> [ <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>
<GROUP-LABEL> [ <RECORD-ROUTE> ]
Figure 7. Resv message
6. Extended Object format
6.1 Hello object for group management
The purpose of this message is to allow a server to maintain the NIB.
The hello message with hello object periodically transmits to a
server. The modified hello object is shown in Figure 8. This object
has explicit route object to indicate a particular path from server
to each LSR within a MPLS domain.
Choi, et. al. Expires August 2003 [Page 9]
Group label allocation mechanism in MPLS network March 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src-Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst-Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flg|L| Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flg
If set to one, this message is used for group management.
Otherwise, this message doesn't use explicit route object.
Figure 8. Hello object
6.2 Group label object
The group label is recognized to all of the LSRs within point-to-
multipoint label switched path of a single MPLS domain. Since the
Path message reserves the traffic engineered explicit registered in
NIB, this label may be carried by Resv message and forwarded to the
reverse explicit routes.
If a node handles the Resv message with the common group label object,
this node can join the point-to-multipoint communication.
The group label object has the following format:
LABEL class = 16, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Group label object
6.3 Group label request object
To establish a point-to-multipoint communication, the sender creates
path message with label request object for group label allocation.
This label request object specifies the range of group label and
triggers the nodes registered in NIB to allocate a group label and to
place the group label of Resv message. The group label must be
allocated from that range. The group label request object is shown in
Figure 10.
Choi, et. al. Expires August 2003 [Page 10]
Group label allocation mechanism in MPLS network March 2003
class = 19, C-Type = 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flg| Reserved | Minimum group label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum group label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flg
If set to one, it is used for group label request
Otherwise, it is used for generic label request.
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Figure 10. Group label request object
7. Other issues
This document specifies that only sender creates the group label
request object and sends the Path message with group label request.
the rest of LSRs within a single MPLS domain becomes receiver,
therefore, it is possible to perform unidirectional point-to-
multipoint communication. The research for bidirectional point-to-
multipoint communication remains in the future, which two or more
LSRs not only receive Path message from a single node but also create
and send Path message to a single node.
8. Security considerations
This document does not have any security concerns. The security
requirements using this document are described in the referenced
documents.
Choi, et. al. Expires August 2003 [Page 11]
Group label allocation mechanism in MPLS network March 2003
8. References
[1] D. Awduche, et al.. "Requirements for Traffic Engineering over
MPLS", September 1999.
[2] E. Rosen, et al.. "Multiprotocol Label Switching Architecture",
January 2001.
[3] L. Andersson, et al.. "LDP Specification", January 2001.
[4] D. Awduche, et al.. "RSVP-TE: Extensions to RSVP for LSP Tunnels",
December 2001.
[5] B.Jamoussi, et al.. "Constraint-Based LSP Setup using LDP",
January 2002.
[6] D. Ooms, et al.. "Overview of IP Multicast in a Multiprotocol
Label Switching Environment", August 2002.
[7] S. Yasukawa, et al.. "Extended RSVP-TE for Point-to-Multipoint
LSP Tunnels-00", Internet Draft, January, 2003.
[8] "B-ISDN network requirements", ITU-T Recommendation I.313,
September 1997.
Choi, et. al. Expires August 2003 [Page 12]
Group label allocation mechanism in MPLS network March 2003
9. Author's Addresses
Jun Kyun Choi
Information and Communications University (ICU)
58-4 Hwa Ahm-Dong, Yusong-Gu, Taejon
Korea 305-732
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Sun Hee Yang
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6122
E-mail: shyang@etri.re.kr
Hyoung Jun Kim
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6576
E-mail: khj@etri.re.kr
Ki Shik Park
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6041
E-mail: kipark@etri.re.kr
Min Suk Sung
Information and Communications University (ICU)
58-4 Hwa Ahm-Dong, Yusong-Gu, Taejon
Korea 305-732
Phone: +82-42-866-6198
Email: mssung@icu.ac.kr
Choi, et. al. Expires August 2003 [Page 13]
