Internet Draft Jun Kyun Choi Document: draft-choi-mpls-grouplabel-requirement-01.txt Min Suk Sung Expiration Date: April 2004 ICU Sun Hee Yang Hyoung Jun Kim Jae Hoon Yoo Hyeong Ho Lee ETRI November 2003 Requirements for multicast service using a group label over MPLS 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 becomes more important, the special label should be allocated in support of group management and maintenance. The allocation mechanism of a group label can be applied to a point- to-multipoint(P2MP) communication in MPLS networks. Currently used label is locally significant, while this group label should be common object within a single MPLS domain. This document presents a set of requirements for multicast service using a group label over Multiprotocol Label Switching(MPLS). It identifies functional and performance capabilities required to allocate a group label in master-slave network and peer to peer network, which facilitates efficient and reliable group communication and Quality of Service(QoS) in MPLS domain. It also identifies functional capabilities required to implement convergence services related to Content Distribution Network(CDN) and Virtual Private Choi, et. al. [Page 1] Requirements for multicast service using a group label over MPLS November 2003 Network(VPN). These capabilities can be used to provide high quality and scalable service. This document includes the allocation mechanism of a group label in order to perform unidirectional P2MP communication. 0. Comparison with "draft-yasukawa-mpls-p2mp-requirement-00.txt" (This section is to be removed before publication.) 0.1 this document We propose a group label which is globally unique within a single MPLS domain and then provide multicast service using a group label. This document presents a set of requirement for multicast service using a group label over MPLS and then identifies allocation mechanism of a group label to perform unidirectional point to multipoint(P2MP) connection. In comparison with 'draft-choi-mpls- grouplable-requirement-00.txt' document, we add the requirement of CDS/VPN convergence network to this document. 0.2 draft-yasukawa-mpls-p2mp-requirement-00.txt This document presents a set of requirement for P2MP capability extension to Multiprotocol Label Switching(MPLS). The functional and performance extensions about Content Distribution Network(CDN) and CDN/VoIP/VPN service convergence network are described. 0.3 differences our draft considers multicast service using a group label in two kinds of network. One is master-slave network. The other is peer to peer network. Requirements, allocation mechanism of a group label and service type can be dealt with each network topology. On the other hand, yasukawa’s draft refers to a set of CDN service and other service convergence network. Then, P2MP extensions which are required to these services are identified. Conventions 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. Choi, et. al. [Page 2] Requirements for multicast service using a group label over MPLS November 2003 Table of Contents 1. Introduction.....................................................4 2. Definition.......................................................4 2.1 Group Label.....................................................4 2.2 Group Communication based on Client-Server Model................5 2.3 Group Communication based on Peer Model.........................5 3. Requirements for Multicast Service using a Group Label...........5 3.1 Master-Slave Network............................................5 3.1.1 Group Label distribution......................................5 3.1.2 Group Label Management........................................6 3.1.3 Designing the position of master node.........................6 3.1.4 QoS Control for P2MP Communication using a Group Label........7 3.1.5 Traffic Engineering for P2MP connection using a Group Label...7 3.1.6 IPv4 / IPv6 support...........................................7 3.1.7 Interoperability between P2P and P2MP connection..............7 3.2 Peer to Peer Network............................................7 3.2.1 Group Label distribution......................................8 3.2.2 Group Label Management........................................8 3.2.3 Scalability...................................................8 4. Requirements for service convergence network.....................9 4.1 Service Type....................................................9 4.2 CDS/VPN service convergence network............................10 4.2.1 Multicast routing information mechanism......................10 4.2.2 Tunneling mechanism..........................................10 4.2.3 Security support.............................................11 5. Communication Mechanism for Multicast Service...................11 5.1 Procedures for setting up Unidirectional P2MP Communication....11 5.2 Joining Mechanism..............................................12 5.3 Leaving Mechanism..............................................13 6. Extended Format for Multicast Service...........................13 6.1 Required Message...............................................13 6.1.1 Path Message.................................................14 6.1.2 Resv Message.................................................14 6.2 Extended Object................................................15 6.2.1 Hello object for Group Management............................15 6.2.2 Group Label Object...........................................15 6.2.3 Group Label Request Object...................................16 Security Considerations............................................16 References.........................................................16 Author's Address...................................................18 Choi, et. al. [Page 3] Requirements for multicast service using a group label over MPLS November 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(P2MP) communication. In existing MPLS technology, label switching is done so that fast and simple forwarding can be performed and this label is local significant. In order to facilitate group communication, a group label which is globally unique within a single MPLS domain should be supported. This label can distinguish each P2MP LSP when a edge node joins several P2MP connections. This multicast service using a group label can be applied Layer 2 Virtual Private Network(L2VPN). The group label is the same role as VPN ID. Therefore, a single VPN can be communicated with other VPNs within P2MP connection using a group label. A group label is allocated using Resource Reservation Protocol- Traffic Engineering(RSVP-TE). Appropriate admission control should be done according to requested QoS degree. In case of multicast or broadcast traffic type, branch node should perform replication function for path message and merging function for resv message. Using QoS mechanism such as Differentiated Service(DiffServ), we can provide prioritized service. Billing mechanism also can be applied. This document presents a set of requirements for multicast service using a group label over Multiprotocol Label Switching(MPLS). It identifies functional and performance capabilities required to allocate a group label in master-slave network and peer to peer network, which facilitates efficient and reliable group communication and Quality of Service(QoS)in MPLS domain. It also identifies functional capabilities required to implement convergence services related to Content Distribution Network(CDN) and Virtual Private Network(VPN). This document includes the allocation mechanism of a group label in order to perform unidirectional P2MP communication. 2. Definition 2.1 Group Label A group label is a common object to establish and maintain the P2MP connection and globally unique within a single MPLS domain. Choi, et. al. [Page 4] Requirements for multicast service using a group label over MPLS November 2003 The allocation mechanism of a group label is done in two kinds of network using RSVP-TE signaling protocol. One is server-client based network and the other is peer to peer based network. 2.2 Group 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 P2MP connection can be established using a single server locally. This server has two functions; one is a replication function for Path message with group label request object and the other is a merging 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. 2.3 Group 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 P2MP 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 P2MP 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 P2MP 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 P2MP 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. 3. Requirements for Multicast Service using a Group Label 3.1 Master-Slave Network 3.1.1 Group Label distribution Using RSVP-TE signaling protocol for allocating a group label, messages of RSVP-TE can be distributed differently according to the incoming traffic type toward master. In case of unicast traffic, Path message is distributed through the route so that a group label can be assigned to each LSR of the route in point to point(P2P) connection. In multicast or broadcast traffic, master should be capable of Choi, et. al. [Page 5] Requirements for multicast service using a group label over MPLS November 2003 replicate Path message the same as the number of receiver. A master also should have merging function to forward RSVP message from multiple receivers toward a single sender. P2MP connection has different dynamics compared with P2P connection because the topology of receivers is changed frequently. A group label is required to distinguish each P2MP connection O Joining Mechanism Master can have both all P2MP connection and corresponding group label information. A receiver can dynamically request to join a certain P2MP communication. If the joining request of new node is traffic-negotiable, master assigns the group label which is exactly matched to requested P2MP communication. Otherwise, that request must be rejected. Each master of the P2MP connection is required to check the residual resource and traffic parameter such as delay, loss, etc. O Leaving Mechanism In case the already joined node wants to leave in the P2MP session with the group label of certain QoS level, that node can request to the master. Then, the explicit route of the receiver is torn down. Since the process of joining or leaving is dynamically performed, a master should periodically check the correct and updated information. 3.1.2 Group Label Management After establishing a P2MP connection, a common group label is assigned to all the LSRs within the P2MP connection. A master should have the topology information of established P2MP connection and mapped group label information. Besides, whenever adding or removing a leaf node, master should have correct updated information. In customer's place, satisfactory service can be provided because of distributing a group label in advance. Therefore, service verification is easily done through group label management. 3.1.3 Designing the position of master node P2MP capability can largely improve the effective usage of network resources such as bandwidth and link utilization. Therefore, the calculation of master's location as a branch node is automatically or administratively required to be done in order to place at optimal position. It also is required to use information related to underlying protocol such as IGP traffic engineering extension or offline management tool. Choi, et. al. [Page 6] Requirements for multicast service using a group label over MPLS November 2003 3.1.4 QoS Control for P2MP Communication using a Group Label A common group label is assigned to each P2MP communication. The group label is required to identify each P2MP connection as well as control QoS level regarding bandwidth, delay, loss and other performance parameters. Therefore, QoS control by a group label should support QoS or Class of Service(CoS) such as Expedited Forwarding(EF), Assured Forwarding(AF) and Default(Best Effort) style of differentiated service. 3.1.5 Traffic Engineering for P2MP connection using a Group Label Because of frequent changes of topology in joining or leaving leaf nodes, traffic engineering including fault location detection and fault recovery should be considered as a important function. In case link failure occurs in P2MP connection using a group label, the information related to failure is promptly advertised to a master and rerouting function should be performed. At that time, rerouted explicit route is done according to administrative policy. The most important requirements on the rerouting process is to avoid traffic disruption. Therefore, the concept of make-before-break is strongly recommended. This shares resources in the common part where both old P2MP and new P2MP connection exist. After breaking down old P2MP connection, the used traffic and resources is switched to new P2MP connection so that rerouting can be successfully done. In P2MP topology, a single common rerouting mechanism is required because multiple paths can be rerouted at once. 3.1.6 IPv4 / IPv6 support This extension must support both IP4/IPv6 transmissions 3.1.7 Interoperability between P2P and P2MP connection According to incoming traffic type toward sender, a master should use ether P2P or P2MP efficiently. It also should be supported that multiple P2P connection are aggregated to establish P2MP. In case a P2P connection is needed over already established P2MP connection using a group label, group label space should be shared between P2P and P2MP connection. Link resource is also required to be shared between P2P and P2MP connection. 3.2 Peer to Peer Network Choi, et. al. [Page 7] Requirements for multicast service using a group label over MPLS November 2003 3.2.1 Group Label distribution Using RSVP-TE signaling protocol for allocating a group label, All nodes should distribute Path messages to every nodes within a single MPLS domain. After receivers check whether requested QoS is acceptable, receivers sends Resv message to only reasonable nodes. A node becomes a sender and a receiver at the same time. Therefore, a single MPLS network consists of P2MP connection using a group label in a full mesh topology. In order to process multicast or broadcast traffic, all nodes within a single MPLS domain are required to perform replication and merging function. All P2MP connections should accommodate P2P as well as P2MP communication according to customer request. O Joining Mechanism Since there is not any master in a P2MP connection, all nodes can directly join at any time, however all nodes joining certain P2MP communication should inform other group members. Other group members can reject a new request according to residual resource and traffic parameter such as delay, loss, etc. O Leaving Mechanism In case the already joined node wants to leave in the P2MP session with the group label of certain QoS level, that node can notify other group members and then immediately leave. Then, the explicit route of the receiver is torn down. Since all nodes can perform the process of joining or leaving for themselves, each node should periodically check the correct and updated information. 3.2.2 Group Label Management All nodes can manage only certain group label which they use. That is, each node is required to have the information of group label which belongs to itself. For example, the node which attends two kinds of P2MP communication should manage two different group labels. 3.2.3 Scalability In this network, joining or leaving process is performed regardless of the memory size of master. A node easily joins or leaves through exchanging the information of a group label each other so that this can be a scalable solution. Since unlimited scalability can reduce QoS, appropriate policy is required. Choi, et. al. [Page 8] Requirements for multicast service using a group label over MPLS November 2003 4. Requirements for service convergence network 4.1 Service Type We can classify P2MP service style of master-slave network environment as a Content Distribution Service(CDS). The representative services of CDS are Live Video Distribution, Video Broadcasting, Video-on-Demand service, etc. These services have the following features. First, they require much higher bandwidth. Second, they should last longer session-on-time. Third, they are very sensitive to delay. O Live video Distribution This service is to distribute live video streaming to multiple users on demand basis. The sports real-time broadcasting or e-learning is a delegate example of this service. The basic operation is as follows. A streaming server per Provider Edge(PE) node is located and video stream data is transmitted through this server. Customers who are about to join or leave at certain session need authentication at first and then are able to join or leave using session control signaling. Therefore, P2MP connection using a group label is dynamically created according to the location of receivers. Resource is also dynamically assigned according to receiver request. When a session is established, a proper resource is assigned and when the session is over, resource is released. Therefore, efficient and effective resource management is required. O Video Broadcasting Service This service is to distribute streaming data to multiple users on static connection basis. Digital broadcasting is a delegate example. The basic operation is as follows. A broadcast streaming server is located in center and provides services using multicast technology. A static P2MP connection is established between a sender and multiple receivers. Therefore, a single static P2MP connection can have multicast capability. In customer's place, customers can choose necessary video channel from multiple service channels and then enjoy various service. That is, the service environment which is equipped with high quality, multiple channels and multiple functions can be realized. In service provider's place, service providers can easily keep a number of demands through high quality service of digital broadcasting. Keeping extra frequency band through multiple channels is important effect and multiple functions can improve revenue potentially. Choi, et. al. [Page 9] Requirements for multicast service using a group label over MPLS November 2003 O Video on Demand Service This service is to distribute streaming service to a single receiver on demand basis. The basic operation is as follows. An original VoD streaming server is located at center and provides services using unicast method. Then, several mirror servers are located at near receivers. In case load becomes significantly larger at central server, mirror server is required in order to decentralize the load. Therefore, multiple static P2P connections between a sender accommodating central server and a receiver are established and also between a sender accommodating mirror server and a receiver. This concept decentralizes server load capable of providing services so that QoS of video traffic can be guaranteed. A central server checks remaining bandwidth of each P2P connection and enable new node to join corresponding P2P communication according to requested QoS whenever incoming requests. Therefore, connection failure can be occurred frequently because multiple traffic streams can be entered to a single P2P connection. In order to improve transmission quality and reliable operation, fast reroute mechanism is needed. 4.2 CDS/VPN service convergence network This extended capability must be applicable to CDS/VPN service convergence network. There are several advantages in terms of integrating CDS and VPN service. First, we can get cost-efficient about expanding existing network. Second, scalability and mobility are supported to provide convenient network environment as remote place, mobile users and telecommuting users increase. Second, flexible network operation and management can be realized. 4.2.1 Multicast routing information mechanism To provide multicast service in the CDS/VPN convergence network, All Provider Edges(PEs) must exchange the information of P2MP communication which each PE participates in. the information between CEs connected to the PE is also require. As each PE gets more than one VPN, each PE must get forwarding information table to distinguish the path per interface. 4.2.2 Tunneling mechanism P2P or P2MP Tunnel must be established between PEs. A group label is inserted as a tunnel label at the ingress LER and maintained while Choi, et. al. [Page 10] Requirements for multicast service using a group label over MPLS November 2003 passing a tunnel LSP. Then, this group label is removed at the egress LSR, while existing MPLS label performs label swapping through LSRs. 4.2.3 Security support VPN has possibility of degradation for security and performance in comparison with dedicated network. To manage P2MP tunnel and policy of VPN multicast, authentication and security protocol or mechanism is required such as IPsec, L2TP, PPTP, etc. 5. Communication Mechanism for Multicast Service 5.1 Procedures for setting up Unidirectional P2MP 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 P2MP 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 P2MP communication allocates group label to the Resv message. 5. The server received several Resv messages containing group label perform the merging function. Then, the server creates and sends new Resv message containing group label to a sender. 6. After distributing the Resv message from multiple receiver to a sender, the P2MP LSP is established and starts P2MP communication, which a single sender and two or more receivers are sharing the common group label. +------------------------------------------+ | Hello | | <------ | Choi, et. al. [Page 11] Requirements for multicast service using a group label over MPLS November 2003 | +--------B | | Hello +-----+ | | | -------> | |<---+--------C | | A--------->| S | | | | |<---+--------D | | +-----+ | | | +--------E | | <------- | | single MPLS domain Hello | +------------------------------------------+ Path ---------> +----------------B | <--------- | Resv | | Path | Path --------> +---+ ---------> A--------------| S |--------------C <-------- +---+ <--------- Resv | Resv | | | Path | ---------> +----------------D <--------- Resv Figure 1. Set up for a point-to-multipoint connection 5.2 Joining Mechanism After establishing P2MP 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 P2MP communication. Choi, et. al. [Page 12] Requirements for multicast service using a group label over MPLS November 2003 The procedure of joining mechanism is illustrated in Figure 2. +--------------------------B | | | . | | . | +---+ . | A--------------| S |--------------C | | +---+ | | Join | Join | |<--------------|<-----------------------| | | | | Path | Path | |-------------->|----------------------->| | | | | Resv | Resv | |<--------------|<-----------------------| | | | Figure 2. Joining mechanism 5.3 Leaving Mechanism Among LSRs joining the P2MP 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 3. +--------------------------B | | | . | | . | +---+ . | A--------------| S |---------------C | | +---+ | | | Leave | | Notification |<-----------------------| |<--------------| | | | | | | teardown | | |----------------------->| | | | Figure 3. Leaving mechanism 6. Extended Format for Multicast Service 6.1 Required Message Choi, et. al. [Page 13] Requirements for multicast service using a group label over MPLS November 2003 6.1.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 4. ::= [ ] [ ] [ ... ] ::= Figure 4. Path message 6.1.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 5. ::= [ ] [ ] [ ] [ ... ]