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. ::= [ ] [ ] Choi, et. al. Expires August 2003 [Page 8] Group label allocation mechanism in MPLS network March 2003 [ ... ] ::= 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. ::= [ ] [ ] [ ] [ ... ]