Internet Engineering Task Force C-Y Lee INTERNET DRAFT Nortel Networks Expires April 2000 October 1999 Provisioning Resources for Multicast Traffic in a Differentiated Services Network 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 This document proposes methods to provision resources for multicast groups. It proposes mechanisms that allow multicast delivery paths to be constructed along paths that have been statically provisioned for multicast traffic. In addition to static provisioning, it allows resources to be provisioned dynamically to overcome the difficulties in predicting and provisioning a priori, the amount of resources required for dynamic multicast groups. To prevent the problem of data being multicasted on a path which has not been provisioned for the service level that data is being transmitted : i) when resources are dynamically provisioned they are provisioned at the same time as the distribution path is setup, otherwise ii) multicast delivery paths are only constructed on paths already provisioned statically. 1.0 Overview and Problem Statement Expires April 2000 [Page 1] Internet Draft April 2000 In a differentiated services (DS) network, a customer specifies the service level it requires in an SLS, (Service Level Specification), the technical aspect of an SLA (Service Level Agreement) [DS_FRAME]. A provider will provision resources (link bandwidth and buffers) in the network to offer the service specified in the SLS. The total amount of physical resources available is fixed and has to be provisioned in a static manner. The specific amount of resources required by each service level or category of service level can be provisioned dynamically or statically. The provider will also configure its boundary routers to carry out the necessary actions to ensure data is arriving in the network as specified in the SLS. While provisioning resources in a DS network for example, from point A to a fixed set of egress points seems straightforward, provisioning from point A to any multiple egress points is more challenging. In the former, after resources have been provisioned from point A to a fixed set of egress points, a network provider should ensure that multicast delivery trees are setup in the provisioned paths. In the latter case, since data from A may exit at any egress point(s) the amount of resources required and where they should be provisioned is not obvious. However, since multicast data is sent (e.g from point A to any multiple egress points) on paths (tree) setup specifically for multicast traffic, the resources required to provide the service level specified at point A can be provisioned as the delivery paths are established or maintained. This approach may not be used for unicast IP traffic because unicast IP traffic does not require such paths to be setup. 2.0 Scope In this proposal, data from a source is delivered to all receivers of a group at the service level marked at the ingress to the DS network. This service level is what the source and a DS network has agreed to. Source is the node injecting data to the DS domain and is not necessarily the node which originates the data. Note that data packets are not remarked at any interior nodes. [RSVP-AGG] describes the problems in accommodating heteregeneous receivers (receivers requiring different service level) in a multicast group. Instead of providing different service level to receivers in a multicast group, by changing the service level at branches of a tree leading towards receivers (eg remarking packets at branch points of the multicast tree, where the branch points could be interior nodes in the DS network), we believe heteregeneous receivers can be accommodated by using different groups to multicast different : Expires April 2000 [Page 2] Internet Draft April 2000 a) fidelity of data (similar to using different audio formats for different bandwidth links) or b) encoding layers. An analogy of this is the use of 2 channels for stereo sound. Data from a source node is delivered to all receivers of a group at the same service level. Receivers should subscribe to the group(s) that delivers data at the service level that they can handle. Alternatively, the same multicast group is used for different fidelity of data but the different layers of data are marked with different level of service. For e.g. data from one mono channel will be marked with AF11 and data from the second channel will be marked AF13. When there is congestion, data marked with AF13 will be dropped preferrably over data marked with AF11. 3.0 Provisioning resources for multicast traffic Resources may be provisioned (and deprovisioned) :- 1) statically, using manual configuration or a resource allocation tool e.g a modified RSVP or CR-LDP. Once resources have been provisioned for the service, a provider should influence the construction of multicast distribution trees along the provisioned paths. An example of such a mechanism is described in Appendix A. The scheme allows the redirection of tree setup messages along the provisioned paths. 2) dynamically, during the establishment (or teardown) of multicast delivery trees. Resources can be provisioned dynamically by :- i) having the ingress router send a resource provisioning message (e.g CR-LDP/RSVP) towards the root of the multicast tree (if the ingress is not the root of the multicast tree). Resources will be provisioned at each hop until the root or an on-tree node is reached. Resources from tree to egress points will be provisioned in (ii) below. AND ii) having egress points send resource provisioning messages (e.g CR-LDP/RSVP) towards the root of the multicast tree, along with the tree setup messages. Resources required as specified (in SLS) at ingress points, will be provisioned at each hop until a tree setup message is terminated i.e when it reaches a node already on the tree. Egress nodes may obtain the resources required for a multicast group by: a) sending a query message with Router Alert towards the root. The Expires April 2000 [Page 3] Internet Draft April 2000 ingress router will intercept the message and respond with the amount of resources required for that source or b) sending a resource query message for the group, to all ingress routers (which are assigned to a well-known multicast address) or alternatively to a server/SLS repository. The ingress routers or server will respond with the resources required for each source of the group. (Note: Sources (not on the path towards the root) which do not specify specific groups such as A in Figure 4 below will be ignored in (b) ) The amount of resources that will be provisioned is the sum of of the resources obtained in (a) and the total resources obtained in (b)). The provider will initially set aside a certain amount of resources or an upper bound of resources for multicast traffic. If this amount of resources is exhausted, the resource provisioning message should be rejected and the SLA re-negotiated. If a provider would like to be able to divert certain multicast traffic towards lightly loaded paths or paths which have more dynamic resources available, Appendix A outlines a mechanism which allows functions which can compute such paths to be used for paths selection. Multicast trees can be constructed along these paths and resources can be provisioned dynamically as well in this case. 4.0 Providing "1 to a fixed set of egress points" service This kind service is useful when a source has a fixed set of egress points to send multicast data to. 4.1 Static Provisioning As an example the SLS at attachment point A: EF-Mark : 1Mbps : Egress point B, C, D : Discard non-conforming traffic A (ingress) /|\ / | \ (egress) B | \ | \ | \ C D (egress) (egress) Figure 1 The provider agrees to carry traffic up to 1Mbps from source A to Expires April 2000 [Page 4] Internet Draft April 2000 egress B,C and D. Resources are statically provisioned between source A and the specified egress points according to the ingress Service Level Specification(SLS). Multicast routes should only be setup on provisioned paths (using the mechanism described in Appendix A e.g), this ensures data from source A is only sent on B,C, and/or D. In addition to the egress points B,C and D, an source may also specify the group ranges or root prefixes of the groups it wants to send data to. The policier at A will ensure/condition traffic send from A conforms to the bandwidth specified. 4.2 Dynamic Provisioning In the example below, if resources are provisioned only when C is being grafted to the multicast distribution tree of G1, then the resources between C and X may be used by other services instead. This improvement in resource utilization can be obtained if resources are dynamically provisioned. A F (ingress) (ingress) /* | EF/ * X--------| (egress) B *| *| *|AFx *| C D Figure 2 5.0 Providing "1 to any multiple egress points" service 5.1 Static Provisioning Static provisioning of one to any multiple egress points may not be accurate or feasible, as can be seen below. AF11-Mark : 1Mbps: Any 2 egress points : Excess traffic handled by marking with BE. A (ingress) /| \ G1 / | \ (egress) B | \ | \ G1| \ C D Expires April 2000 [Page 5] Internet Draft April 2000 (egress) (egress) Figure 3 In a dynamic multicast group, the provider would have to guess the delivery paths of multicast traffic and approximate the resources required in the network. Since the receivers in a multicast group can be dynamic, this could result in :- i) services not being offered at the service level agreed to, if the parts of the network utilized by multicast groups is not adequately provisioned ii) under-utilized network resources if the provider incorrectly estimated the multicast paths of groups. In addition receivers of a group or service level may experience very different service level, depending on whether they are in the hit- or-miss paths. If the provider choose to spread the resources in the paths from an ingress to all possible egress points, the multicast traffic may be delivered consistently below the service level specified by the customer at ingress. 5.2 Dynamic Provisioning AF11-Mark : 1Mbps: Any 2 egress points : Excess traffic handled by marking with BE. towards root of tree (from a source) A F (ingress) (ingress) /| \ G1 / | \ (egress) B | \ | \ G1| \ G3 C D (egress) (egress) Figure 4 Resources are provisioned while the tree is being constructed. Appendix A described a mechanism to accomplish this. When an egress node receives a message to graft an egress point to the tree, it will divert that message to a resource allocation entity, which will provision the total amount of resources required for this group. The amount of resources required is the total sum of all resources required by all ingress points (not leading towards the root of the tree) and the source where this graft message will be Expires April 2000 [Page 6] Internet Draft April 2000 sent towards, i.e. the resources required by ingress A and F. The amount of resources required by each source is obtained by sending a query message to the ingress router as described in Section 3.0. The resources specified by other sources leading towards the root of the tree is not included because data from those sources will not reach this new egress point (the new egress point only have one parent ingress point). Resources would only be provisioned and the graft message forwarded if there are sufficient resources (as defined by the network operator) for the service level requested. This procedure is repeated at subsequent hops, until the graft message is terminated or there is insufficient resources at a node. Resources are deprovisioned when multicast delivery paths are removed. 6.0 Provisioning resources for new sources to a group The above sections assume the sources of a multicast group are known a priori and have negotiated SLAs prior to the setup of multicast trees/groups. What happens when a source would like to send data to an existing multicast group but does not have an SLS negotiated for that group yet? This is actually a relatively simpler problem because the resources required for the new source can be provisioned along existing delivery paths. A source may dynamically or use off-line means to request for a service level for a multicast group. The ingress provider router will attempt to provision resources for the new source by multicasting resource provisioning message to the multicast group. If the resource demand of the new source cannot be met the service request can be degraded or denied. 7.0 Observations Since no data is sent to a path in the multicast tree unless the SLS is satisfied and/or resources are provisioned, there are no concerns of data being transmitted down a branch with lower service level or resources not provisioned. The problem with some branches receiving packets before resources are allocated or at a service level higher than specified is described in [RSVP-AGG]. Expires April 2000 [Page 7] Internet Draft April 2000 8 Acknowledgments The author would like to thank Nabil Seddigh and Elwyn Davies for their 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 8] 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 [RSVP-AGG] S. Berson, S.Vincent Aggregation of Internet Integrated Services State, Internet Draft, August 1998 [MCPROV] C-Y Lee, N. Seddigh Controlling the number of egress points in dynamic multicast groups, Internet Draft October 1999 [MC-TE] C-Y Lee, L. Andersson, K. Carlberg, B. Akyol Engineering Paths for Multicast Traffic , Internet Draft October 1999 Expires April 2000 [Page 9] Internet Draft April 2000 Appendix A This appendix is extracted from [MC-TE] and describes a mechanism to provision resources as the multicast tree is setup. For further details, please refer to [MC-TE] A.1 At the Egress Router At any egress router (a router where multicast data exits the network) the IP fields of interest in the control message (referred to as FEC here, for lack of a better term), the associated path selection mechanisms are defined in a Traffic Configuration table. These FECs correlate to the control messages of routing protocols. (eg, destination = root prefix/target-node address, ToS=codepoint). Note that the message carrying this information traverses the network from egress to ingress. The path selection mechanisms can be based on, a static table or a Constraint Based Routing (CBR) table, or a path selection algorithm (dynamic). The resources required are obtained from the ingress using the mechanism described in Section 3.0 and placed in the Traffic Configuration table. Figure 1 shows the passage of control messages in an egress router (dotted lines) and the interface between the various entities in the router (+++ lines) When a join message arrives at the egress router the packet is processed by the appropriate multicast routing protocol, to setup multicast forwarding states. If there are already forwarding states, a join message is discarded, otherwise, the multicast routing protocol calls an API provided by the Multicast Traffic Engineering (MCTE) entity to get the next hop to the root. Expires April 2000 [Page 10] Internet Draft April 2000 ---------- | MCTE API | ---------- + + ------------------------- | Multicast Routing | ------------------------- ^ | | | | v ____________ | ------------ ______________________ | IP|Ctl Msg| ---->| | MCTE | ----> | IP | MCTE | Ctl Msg | _____________ ----------- _______________________ + + + --------------- | FEC,Path and | | Resource | | Specification | ---------------- Fig. A.1 At the egress (wrt data flow) router After the multicast forwarding states are setup, the control message is forwarded towards the root. If the control message matches a defined FEC, it is diverted to the MCTE entity. How the outgoing control message is diverted to the MCTE entity is implementation dependent. The MCTE entity calls an API provided by the MRP (Multicast Routing protocol)to find out whether the control message is a path setup (join), path teardown (leave) message or other maintenance message. If it is a path setup, resources specified in the Traffic Configuration table is allocated, if it is a path teardown message the resources are deallocated. If it is a maintenance control message, the control message is forwarded as is without any MCTE header and will be forwarded by the multicast routing protocol in intermediate routers as per normal. If it is either a path setup or path teardown message, the MCTE entity prepends a MCTE header - containing the FEC, explicit routes (provided by the path selection mechanism) resources required (e.g Traffic Parameter, service level) and the protocol id of the control message. The IP protocol id is set to IPPROTO_MCTE. The MCTE header is placed between the IP header and the control message. Resources as specified in the Traffic Configuration table Expires April 2000 [Page 11] Internet Draft April 2000 are allocated/deallocated before the MCTE message is forwarded to the next hop returned by the path selection mechanism specified. To allow other routers to process this MCTE message (which includes the control message), the packet will be labeled as Router Alert. Expires April 2000 [Page 12] Internet Draft April 2000 5.2 At the Intermediate Routers Figure 2 shows the passage of control messages in an intermediate router (dotted lines) and the interface between the various entities in the router (+++ lines) ---------- | MCTE API| ---------- + + ------------------------- | Multicast Routing | ------------------------- ^ | __________ | | __________ |IP|Ctl Msg| | | |IP|Ctl Msg| ____________ | | ____________ | v _______________ ---------- ------------ ________________ |IP|MCTE|CtlMsg|---> | MCTE | | MCTE | ----> |IP|MCTE|Ctl Msg| | | | Entity | | Entity | | | ________________ ---------- ------------ _________________ + + + + + + ---------------- | MCTE | | State | ---------------- Fig. 2 At an intermediate router When the next hop (or other intermediate nodes) receives the packet with Router Alert, it will be taken out of the forwarding path and directed to the MCTE entity since the IP protocol id is IPPROTO_MCTE. The MCTE entity allocates/deallocates the resources requested by the MCTE message, creates a transient state for the MCTE message, called the MCTE state, for short. The appropriate mutlicast routing protocol (MRP), depending on the value of protocol id in the MCTE message, is then invoked. The exact mechanisms used in the router to accomplish this is implementation dependent. The MRP creates the forwarding state for the group and forwards the join message towards the root. As in the egress router, the next hop Expires April 2000 [Page 13] Internet Draft April 2000 towards the root is obtained from an MCTE API. Since the FEC for this control message matches the MCTE state created earlier, the join message is diverted to the MCTE entity. The MCTE entity placed the corresponding MCTE header on the control message and forwards the message to the next hop. The transient MCTE state is removed at this point. Note that the FEC is only configured at the egress router (wrt to multicast data), intermediate routers are informed of the FEC information by previous hops. Similarly, the explicit or constraint route is only configured or computed at the egress router; the next hop and other intermediate nodes learn of the explicit routes via the explcit route list propagated from the egress router. Authors' Information Cheng-Yin Lee Nortel Networks PO Box 3511, Station C Ottawa, ON K1Y 4H7, Canada leecy@nortelnetworks.com Expires April 2000 [Page 14]