Internet Engineering Task Force C-Y Lee INTERNET DRAFT Nabil Seddigh Expires April 2000 Nortel Networks October 1999 Controlling the number of egress points in dynamic multicast groups 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The amount of resources required by a source to send data to a multicast group within a network is dependent on the service level the source requested and the number of egress points for the group in a network. Since the egress points in a multicast group can change during a multicast session, a source node would not know how many or which egress points it would be sending to when it specifies the service level it requires for multicast data. This document describes methods to control the number of egress points of a dynamic multicast group in a differentiated services (DS) network. A source node specifies the bandwidth, type of service and a limit on the number of egress points that it wants to send multicast data to. If this limit on the number of egress points is reached, no further egress points will be grafted to the branch of the multicast tree rooted at this source node. 1.0 Problem Statement Expires April 2000 [Page 1] Internet Draft April 2000 This document considers a method for dynamic provisioning of network resources to achieve the service requirements of multicast groups in a DS network. The method considered is a source-based model where the source informs the network provider of the service level, bandwidth required and maximum number of egress points that it wants to send data to. Note that source is the node injecting data to the DS domain and is not necessarily the node which originates the data. In current DS schemes, the source is unable to specify the number of egress points for a multicast tree in a network. Further, a provider will not have advanced knowledge of which receivers will be subscribing to a particular dynamic multicast group at any given time. As such, the provider is unable to pre-provision resources without wasteful resource allocation. 2.0 Approach This proposal describes methods that can be used to control the number of egress points of a multicast group. To allow a source node to limit the egress nodes in a multicast tree, the source node should be able to specify the the maximum number of egress points the source would want to send data to. In a Differentiated Service (DS) network, a source can specify this as part of the Service Level Specification (SLS) which is defined in [DS_FRAME] as the technical aspect of an SLA (Service Level Agreement). In this proposal we consider multicast groups setup using multicast routing protocols which uses graft messages to construct the multicast tree. Other types of tree construction protocols are FFS. In a dynamic multicast group, the boundary DS router at the egress will receive messages to graft egress nodes to the multicast tree. If the grafting of an egress node exceeds the limit on the maximum number of egress points allowed for a particular source then: i) the message to graft an egress node to a tree is discarded, thereby preventing a new egress node from being grafted to the tree or ii) the message to graft an egress node to a tree is redirected to another egress node which is already on the multicast tree or The approach described above assumes that there are suitable PHBs to treat multicast packets. While nothing prevents network providers from marking unicast and multicast packets to be treated by the same PHB, this draft assumes that multicast packets will be handled separately from unicast packets by core routers. This can be facilitated by utilizing one or two classes from the Assured Expires April 2000 [Page 2] Internet Draft April 2000 Forwarding (AF) PHB or assuming the existence of AF-like PHB specifically for multicast traffic. In addition, depending on the requirements of multicast traffic, an EF-like PHB is assumed. The draft also assumes use of a suitable policer at boundary and edge devices. 3.0 Procedure The following is described in terms of a per source tree unless specified otherwise. A per source tree is rooted at the source, whereas a shared tree allows multiple sources to use the same tree to deliver multicast traffic to a group. The extensions for multiple sources to a shared tree is described in Section 5.0. When an egress point requests to be grafted to a multicast tree, the graft message can be diverted to a resource management entity such as RSVP/CR-LDP whose function is to allocate the resources required along the branch of the tree. One way to divert the graft messages to a resource management entity is described in MCAST_TE. Before the resource management entity at the egress router forwards the graft message, it sends a request message to add an egress node, towards the root . This unicast message is sent using a Router Alert option and is sent with the IP destination address set to the root address of the multicast tree. The resource management entity obtains the root address of the multicast tree via an API provided by the multicast routing protocol. The boundary router at the source intercepts the packet and processes it as described in the following paragraphs. When this message arrives at the provider boundary ingress router, the router will verify whether the grafting of a new egress node will exceed the number of egress points specified in the SLS at the source to this branch of the multicast tree: 1) If it does not exceed, the ingress router will send a response message - to allow the grafting of the new egress node and specify the amount of resources to be provisioned. The resource management entity in the egress router provisions the resources required and forwards the graft message [MCAST_TE]. The resources provisioned may be less than specified to take advantage of statistical multiplexing. 2) If it exceeds and the SLS at the source specified that there can be no more than n number of egress points, the ingress router will send a response message to prohibit the grafting of the new egress node. The egress router will then either : a) send a graft redirect message containing a copy of the original Expires April 2000 [Page 3] Internet Draft April 2000 graft message and the nearest 2 egress nodes which are already attached to the multicast tree, to the downstream router. The egress router may obtain the the mapping of multicast group addresses and egress nodes either directly from egress nodes or via a server which stores this information. The resource management entity in the downstream router should then send a new graft message using source routing to redirect the graft message via the nearest egress node listed in the graft redirect message. The second egress node is used if this new graft attempt fails. If the graft succeed, the downstream router will be grafted via an already on-tree egress node, thereby limiting the egress points to the value specified in the SLS. b) If the the graft attempts in (a) fails, the graft message will be discarded. When the boundary router at the source setup state for a path to the multicast tree, it will verify that the SLS at the source has specified an adequate number of egress points for the multicast group that the source is sending data to. If the SLS at a source is defined when delivery paths already exist for the groups the source wishes to send to, the ingress router should verify that the number of egress points specified is adequate for the actual number of egress points for the groups. If it is, send (multicast) a resource provisioning message to these groups to provision the resources required by this source along the existing delivery paths, otherwise data from this source should be discarded. (See [MCPROV] for further details] 4.0 Example The SLS at ingress A is, AFx1-Mark : 5Mbps: Excess traffic handled by marking AFx3, Maximum 2 egress points The SLS at ingress F is, AFx1-Mark : 5Mbps: Excess traffic handled by marking AFx3, Maximum 3 egress points to root to root outside of this domain outside of this domain (ingress) (ingress) A F /| \ / \ / | \ / \ / | \ / \ / | \ / \ / | \ / \ B C D G H (egress) (egress) (egress) (egress) (egress) Expires April 2000 [Page 4] Internet Draft April 2000 Fig 1 Ingress and egress nodes of a per source multicast tree in a diffserv network In Figure 1, A and F are two branches of a multicast distribution tree in a network. If a new egress point D is being attached to the multicast tree, the boundary router at D would verify that the SLS at A has specified enough egress points. In this case, the SLS is at A did not specify an adequate number of egress points, so D will not be grafted to the tree. If another egress point is being attached to the multicast tree via ingress F, the node will be grafted since ingress F specified up to 3 egress points. 5.0 Extensions for shared trees In the case where the multicast delivery tree used is a shared tree, there may be other ingresses (e.g at E and I) which are not on the paths towards the root of the tree (e.g A and F). The SLS at ingress A is, AFx1-Mark : 5Mbps: Excess traffic handled by marking AFx3, Maximum 2 egress points The SLS at ingress F is, AFx1-Mark : 5Mbps: Excess traffic handled by marking AFx3 Maximum 3 egress points The SLS at ingress E is, AFx1-Mark : 2Mbps: Excess traffic handled by discarding, Maximum 4 egress points, G1 The SLS at ingress I is, AFx1-Mark : 1Mbps: Excess traffic handled by discarding, Maximum 2 egress points, G1 to root to root outside of this domain outside of this domain (ingress) (ingress) A F (ingress) E ---> /| \ / \ <--- I (ingress) / | \ / \ / | \ / \ / | \ / \ / | \ / \ B C D G H (egress) (egress) (egress) (egress) (egress) Fig 1 Ingress and egress nodes of a shared multicast tree in Expires April 2000 [Page 5] Internet Draft April 2000 a diffserv network In Figure 1, A and F are two branches of a multicast distribution tree in a network. If a new egress point D is being attached to the multicast tree, the boundary router at D would verify that the SLS at A, E and I have specified enough egress points. In this case, the SLS is adequate at E and I, but not at A, hence node D will not be grafted to the tree. If the boundary router at the ingress point A is is on the path towards the root of the tree, the resource management entity verifies the egress points specified in the ingress SLS against the current number of egress points hanging off this ingress point. If the boundary router at ingress E is not on the path towards the root, the number of egress points in the SLS is compared with the current number of egress points for the multicast group (i.e B+C+D+G+H = 5). E has sufficient egress points specified and hence will be allowed to send data to the group. If an ingress node e.g I do not specify adequate egress points in the SLS, multicast traffic for the group G1 will be discarded at the provider boundary router at ingress I. Expires April 2000 [Page 6] Internet Draft April 2000 8. Acknowledgments The authors would like to thank Elwyn Davies for his helpful comments. 9. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some of the specification contained in this document. For more information consult the online list of claimed rights. Expires April 2000 [Page 7] Internet Draft April 2000 References [CLARK] D. Clark and J. Wroclawski, "An Approach to Service Allocation in the Internet", Internet Draft [DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet Draft, May 1998. [DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [DSFW] Y.Bernet, et al A Framework for Differentiated Services, Internet Draft February 1999 [AF] J.Heinanen, F.Baker, W. Weiss, J. Wroclawski Assured Forwarding PHB Group RFC2597, June 1999 [EF] V.Jacobson, K. Nichos, K. Poduri, Expedited Forwarding Per Hop Behavior, RFC2598, June 1999 [MCPROV] C-Y Lee, Provisioning Resources for Multicast Traffic in a Differentiated Services Network, Internet Draft October 1999 Expires April 2000 [Page 8] Internet Draft April 2000 Authors' Information Cheng-Yin Lee Nortel Networks PO Box 3511, Station C Ottawa, ON K1Y 4H7, Canada leecy@nortelnetworks.com Nabil Seddigh Nortel Networks PO Box 3511, Station C Ottawa, ON K1Y 4H7, Canada nseddigh@nortelnetworks.com Expires April 2000 [Page 9]