Network Working Group H.S. Byun Internet Draft M.J. Lee Expires: December 2006 Ewha Womans Univ. June 20, 2006 Extensions to P2MP RSVP-TE for Hose Model Provisioning in L3 PPVPN draft-byun-vpn-provision-rsvp-te-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." 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. This Internet-Draft will expire on December 20, 2006 Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes extensions to point to multipoint resource reservation protocol traffic engineering (P2MP RSVP-TE) for hose model based quality of service (QoS) provisioning in Layer 3 Provider Provisioned Virtual Private Network (L3 PPVPN). This protocol enables dynamic and automatic resource reservation according to hose-specific or VPN-specific state provisioning, which are the resource Byun Expires December 20, 2006 [Page 1] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 provisioning mechanisms for hose model. Protocol elements and procedures for this solution are described. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction................................................3 2. Terminologies...............................................3 3. Overview....................................................3 4. Path Message................................................3 4.1. Path Message Format.....................................3 4.2. Path State Block (PSB)..................................3 4.3. Path Message Processing.................................3 5. Resv Message................................................3 5.1. Resv Message Format.....................................3 5.2. Resv State Block (RSBs).................................3 5.3. Reservation Style.......................................3 5.4. Resv Message Processing.................................3 6. New and Updated Message objects..............................3 6.1. VPN SENDER TEMPLATE object..............................3 6.1.1. VPN IPv4 VPN SENDER TEMPLATE object................3 6.1.2. VPN IPv6 VPN SENDER TEMPLATE object................3 6.2. VPN FILTER SPEC object..................................3 6.2.1. VPN IPv4 FILTER SPEC object........................3 6.2.2. VPN IPv6 FILTER SPEC object........................3 6.3. SUB_LABEL object........................................3 7. Security Considerations......................................3 8. IANA Considerations.........................................3 8.1. New Class Numbers.......................................3 8.2. New Class Types.........................................3 9. Acknowledgments.............................................3 10. References.................................................3 10.1. Normative References...................................3 10.2. Informative References.................................3 Author's Addresses.............................................3 Intellectual Property Statement.................................3 Disclaimer of Validity..........................................3 Copyright Statement............................................3 Acknowledgment.................................................3 Byun Expires December 20, 2006 [Page 2] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 1. Introduction Among the standard modes of QoS in L3 PPVPN, an aggregate Customer Edge (CE) interface level QoS ("hose" level QoS) is defined [RFC4031]. In the "hose" level QoS, sometimes also referred to as the "hose" model, hose Service-Level Specification (SLS) just defines traffic parameters in conjunction with the QoS objectives for traffic exchanged between a CE and a PE (Provider Edge) for traffic destined to a set of other sites in the VPN. In other words, the hose SLS, defines the requirement in terms of all packets transmitted from a given VPN site toward the service provider network on an aggregate basis instead of the complete traffic matrix between each CE pairs. There are several advantages to the "hose" model from a customer perspective. Specification of VPN customer QoS requests becomes simple. It also provides flexibility by allowing packets to and from a given site to be distributed arbitrarily over other sites. Customers can also obtain statistical multiplexing gains on the CE interface level since hose rate is on an aggregate basis. From a service provider's perspective, though, it presents more challenging resource management problems due to the need to meet the service level agreements (SLAs) with a very week SLS. Feasibility of using "hose" model in practice requires for a bandwidth efficient resource provisioning mechanism. To cope with the challenges, resource provisioning for the "hose" model are studied extensively. Resource provisioning for the "hose" model can be implemented in several ways[Duf2002]. The hose-specific or VPN-specific state provisioning mechanisms, among those provisioning mechanisms, enable a Service Provider (SP) to make use of the hose-specific state parameters in order to achieve resource sharing. For hose-specific provisioning, a Hose tree that is rooted at an ingress PE of a VPN and spanning all of the egress PEs of the VPN can be formed. Hereinafter, we refer this hose tree as a Hose LSP. A Hose LSP is comprised of multiple S2L sub-LSPs. The S2L Sub-LSP is the path from the ingress PE to one specific egress PE[RFC4461]. The SP can leverage the knowledge of hose parameters to determine the amount of resources to be reserved on the Hose LSP. The amount of resources to be reserved on a certain link of a Hose LSP is the minimum of ingress hose rate and the total egress hose rate of the sites that are on the "destination side" of the link. Note the reserved resources on the Hose LSP are shared by all of the S2L sub-LSPs of the Hose LSP. By taking into account the VPN-specific state parameters, further capacity reduction can be obtained. A graph connecting all of the ingress and/or egress sites of a VPN can be formed. Hereinafter, it Byun Expires December 20, 2006 [Page 3] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 is referred to as a VPN tunnel. The entire hose parameters of the VPN, i.e., the VPN-specific state parameters, are taken into account to determine the amount of resources to be reserved on the links of this graph. The amount of resource to be reserved on a certain link of the graph is the minimum of the total ingress rate of the sites that are on the "source side" of the link and the total ingress rate of the sites that are on the "destination side" of the link. Note the reserved resources on the graph are shared by all of the S2L sub-LSPs of the VPN. Yet another issue on the VPN QoS provisioning is related to applying the above provisioning mechanisms in a real network. In order to deploy the mechanisms in practice, a resource reservation protocol is necessary for dynamic and automatic provisioning of networks with hose-specific or VPN-specific state. There exists resource reservation protocol such as [P2MP RSVP-TE], proposed for building P2MP TE LSPs in the MPLS networks. The [P2MP RSVP-TE] is an extended protocol of [RFC3209] for setting P2MP TE LSPs. It is for transmission of multicast data. In the [P2MP RSVP-TE], a P2MP LSP comprises of one or more S2L sub-LSPs starting from same source. Also, a P2MP Tunnel comprises of one or more P2MP LSPs. The S2L sub-LSPs belonging to a P2MP LSP can share the reserved resource for the P2MP LSP. The way that S2L sub-LSPs of a P2MP LSP share resources is the same as how the resources are shared by the S2L sub- LSPs of a Hose LSP. Likewise, the S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP Tunnel can share resources where they share hops. The way that the S2L sub-LSPs of a VPN tunnel share the resources is the same as how the S2L sub-LSPs of a P2MP Tunnel share the resources. In order to deploy hose-specific or VPN-specific state provisioning, the [P2MP RSVP-TE] can be used to set a Hose LSP or a VPN Tunnel. It enables all of the S2L sub-LSPs belonging to the Hose LSP or the VPN Tunnel to share resources where they share hops. Although the [P2MP RSVP-TE] provides the setup and the resource sharing of Hose LSPs or VPN Tunnels, it is not appropriate for hose- specific or VPN-specific state provisioning by several reasons as follows. o [P2MP RSVP-TE] can not support the assignment of labels and the label switching for transmission of unicast data. The S2L sub-LSPs that belong to the same P2MP LSP should share labels where they share hops. However, the hose-specific or VPN-specific state provisioning need separate labels for each S2L sub-LSP in order to transmit unicast data. Byun Expires December 20, 2006 [Page 4] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 o If multiple user sites belonging to the same VPN are attached to a single ingress PE, these SHOULD be identified from each other. o The mechanism to compute the amount of resources to be reserved on a link according to the hose-specific or VPN-specific state provisioning differs from the [P2MP RSVP-TE]. Therefore, the [P2MP RSVP-TE] is not sufficient for hose-specific or VPN-specific state provisioning. This document describes extensions to [P2MP RSVP-TE] for hose- specific or VPN-specific state based QoS provisioning in L3 PPVPN. 2. Terminologies This document uses terminologies defined in [RFC4031], [RFC2205], [RFC3209], [RFC4461], and [RFC4110]. The reader is assumed to be familiar with the terminology in [P2MP RSVP-TE] A Hose LSP: A set of one or more S2L sub-LSPs between the pairs of PEs for a VPN. A VPN Tunnel: A set of one or more Hose LSPs of a VPN. 3. Overview This document defines extensions to [P2MP RSVP-TE] protocol to reserve resources according to the hose-specific or VPN-specific state provisioning. This document relies on the semantics of RSVP that [P2MP RSVP-TE] inherits for building Hose LSPs or VPN Tunnels. A VPN Tunnel comprises of one or more Hose LSPs. A VPN Tunnel is identified by a VPN SESSION object. This object is a renaming of the P2MP SESSION object in [P2MP RSVP-TE]. In the VPN-specific state provisioning, all of the S2L sub-LSPs in a VPN Tunnel MUST share the reserved resource for the VPN Tunnel. A Hose LSP is identified by the combination of the VPN SESSION and the VPN SENDER TEMPLATE object. In the hose-specific state provisioning, all of the S2L sub-LSP in a Hose LSP MUST share the reserved resource for the Hose LSP. Path computation aspects for Hose LSP (a hose tree) and VPN Tunnel (a VPN tree or graph) are outside of the scope of this document. Specifically, the extensions explained in this draft include the RSVP message formats and the structures of path state block (PSB) and Byun Expires December 20, 2006 [Page 5] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 reservation state block (RSB). In addition, for the assignment of labels and the label switching for transmission of unicast data, S2L LABEL object is added in the S2L sub-LSP descriptor defined in the [P2MP RSVP-TE]. In order to identify the multiple user sites belonging to the same VPN and attached to a single ingress PE, Hose ID field is defined and included in the VPN SENDER TAMPLATE and VPN FILTER SPEC objects. The modifications to the processing of RSVP messages, in order to compute the amount of resources to be reserved on a link according to the hose-specific or VPN-specific state provisioning, are described. The extended resource reservation protocol enables resource reservation dynamically and automatically according to hose-specific or VPN specific state provisioning. 4. Path Message 4.1. Path Message Format This section describes modifications made to the Path message format specified in [P2MP RSVP-TE]. The VPN SESSION object is a renaming of the P2MP SESSION object in [P2MP RSVP-TE]. It is composed of the VPN session ID, the VPN tunnel ID and the extended VPN tunnel ID. For the VPN session ID, a multicast group IP address, which needs to be distributed to the PE routers serving a same VPN by the administrator, SHOULD be used. The VPN SESSION object refers only to signaling state and not data plane multicast. The VPN SESSION object identifies a VPN Tunnel. For the VPN-specific state provisioning, all of the S2L sub-LSP in a VPN Tunnel SHOULD share the reserved resource for the VPN Tunnel. VPN SENDER TEMPLATE object of Path message is extended with Hose ID field, and as a result the VPN SENDER TEMPLATE object is composed of the tunnel sender address, the Hose ID, and the LSP ID. The VPN SENDER TEMPLATE object is defined in section 6.1. Tunnel sender address, Hose ID, and LSP ID are included in the VPN SENDER TEMPLATE object. Tunnel sender address specifies the ingress PE by which the Path message is generated. For each hose attached to the PE, unique Hose ID is assigned and a corresponding LSP is established. For the purpose of modifying the route or the reservation state of the Hose LSP for a certain hose, a new Hose LSP can be established, and as a result multiple Hose LSPs may exist for a single hose temporarily. In this case, the Path messages for those Byun Expires December 20, 2006 [Page 6] Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006 Hose LSPs contain the same Hose ID. Therefore, an additional ID is necessary to differentiate those Hose LSPs(the original and newly established Hose LSPs), and LSP ID is deployed to this end. Hose LSPs with the same Hose ID but with different LSP IDs share reserved resources where they share hops. ::= [ ] [ [ | ]...] [ ]