INTERNET DRAFT Giovanni Fiaschi Category: Informational Fabio Poggi Title: draft-fiaschi-qoscapability-ppp-00.txt GianLuca Rolandelli Date: July, 2000 Marconi Expires: January, 2001 A proposal to provide QoS capability for PPP draft-fiaschi-qoscapability-ppp-00.txt 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''. 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 Quality of Service in the IP protocol has been proposed in some service definitions (Int-Serv and Diff-Serv) and in a variety of schemes and supporting protocols (RSVP). These schemes assume, of course, that all the protocols supporting IP links in turn provide a well-defined degree of QoS the IP schemes can rely upon. One of the most common link protocols is PPP. The PPP protocol provides a standard method for transporting multi-protocol datagrams over point-to-point links. It was designed to be used in serial point-to-point links. These ones can be for example PSTN circuits, characterized by a fixed bandwidth and fixed delay. Hence, there was no need to specify QoS mechanisms for PPP: the IP layer (or more generally the network layer) did not take into account the data-link layer to calculate the available resources. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 1] INTERNET DRAFT July 2000 The same is valid for ATM connections carrying PPP sessions: the PPP inherits the ATM QoS characteristics. On the other hand, if the PPP protocol is used over shared media (such as Ethernet) or it is multiplexed over a L2TP tunnel, the bordering conditions change and new solutions have to be developed to guarantee QoS in such a model. This draft presents a proposal to provide "native" QoS capability on the PPP protocol. Two scenarios, in which QoS over PPP may be effective, are considered in this draft: L2TP Access Concentrator (LAC) and PPP over Ethernet (PPPoE). Table of Contents 1.0 Introduction 1.1 Conventions 2.0 LAC 2.1 Network Model 2.2 QoS issues for LAC 2.3 Information Flow 2.4 QoS in underlying protocols 2.5 Other non-ATM Access Network 3.0 PPPoE 3.1 Network Model 3.2 QoS issues for PPPoE Server 3.3 Information Flow 3.4 QoS in underlying protocols 3.4.1 QoS-enabled Ethernet 4.0 References 5.0 Acknowledgements 6.0 Authors' Addresses Fiaschi, Poggi, Rolandelli expires January 2001 [Page 2] INTERNET DRAFT July 2000 1.0 Introduction Quality of Service in the IP protocol has been proposed in some service definitions (Int-Serv and Diff-Serv) and in a variety of schemes and supporting protocols (RSVP). In particular, according to RFC 2475 [4], with Diff-Serv, packets are classified and marked in order to be managed with a particular forwarding methodology based on a "per-hop behavior" on the nodes along their path. Classification, marking, policing, and shaping operations are implemented in the network boundaries or hosts. On the other hand, with Int-Serv [5], IETF has defined a framework that provides individualized quality of service guarantees to individual application sessions. This architecture is based on Reserved Resources and on Call Setup. Moreover, according with RFC 2205 [6], RSVP was developed in order to provide a receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. The RSVP protocol is setup by a host with the aim to request specific qualities of service from the network for particular application data streams or flows. It is also used by routers to deliver Quality of Service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. These schemes above assume, of course, that all the protocols supporting IP links in turn provide a well-defined degree of QoS the IP schemes can rely upon. One of the most common link protocols is PPP [1]. PPP provides a standard method for transporting multi-protocol datagrams over point-to-point links. These links, carrying packets between two peers, are characterized by full-duplex simultaneous bi-directional communications, and are assumed to deliver packets in order. These links can be for example PSTN circuits, characterized by a fixed bandwidth and fixed delay. Hence, there was no need to specify QoS mechanisms for PPP: the IP layer (or more generally the network layer) did not take into account the data-link layer to calculate the available resources. The same is valid for ATM connections carrying PPP sessions: the PPP inherits the ATM QoS capabilities. If the PPP protocol is used over shared media (such as Ethernet) or it is multiplexed over a L2TP tunnel, the bordering conditions change and new solutions have to be developed to guarantee QoS in such a model. Two scenarios, in which QoS over PPP may be effective, are considered in this draft, L2TP Access Concentrator (LAC) and PPP over Ethernet (PPPoE). Fiaschi, Poggi, Rolandelli expires January 2001 [Page 3] INTERNET DRAFT July 2000 1.1 Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 2.0 L2TP Access Concentrator (LAC) This section will analyze the QoS problem for PPP from an L2TP Access Aggregation (LAA) network architecture perspective. In the LAA architecture an ATM Access Network is supposed. It is also supposed (in this Draft) a PVC environment. The PPP sessions starting from the Hosts rely directly over ATM PVCs by means of RFC 2364 (PPP over ATM, or PPPoA). The Network Model is described in session 2.1. 2.1 Network Model The reference circuit is the following: +------------+ +-----------+ | | +--------+ | | +--------+ +----+ | ATM | | Access | | Transport | | Access | |Host|----| Access |----| Server |----| Network |----| Router | +----+ | Network | | (LAC) | | | | (LNS) | | | +--------+ | | +--------+ +------------+ +-----------+ From the PPP point of view, the Access Network is made by Hosts, an Access Server (LAC), and Access Routers (LNS). Hosts have to set up a PPP session with the selected Access Router. The Access Server can be seen as a PPP Switch. In the following of this document the terms LAC and Access Server and the terms LNS and Access Router have to be considered as synonyms. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 4] INTERNET DRAFT July 2000 In the ATM Access Network, we suppose to have one ATM PVC per PPP connection (a dedicated circuit exists between the Host and the Access Server). In the Transport Network, all the PPP sessions for the same ISP are multiplexed and tunneled by means of L2TP (a shared link exists between the LAC and the Access Router). 2.2 QoS issues for LAC Between the Host and the Access Server there is one PVC per PPP connection. So it is reasonable to assume that the PPP inherits the quality of the underlying ATM PVC. As there is a shared link (tunnel) between the Access Server and the Access Router, QoS mechanisms for PPP MUST be provided in the LAC in order to allocate bandwidth for the incoming PPP sessions. To provide the PPP with QoS capability, the PPP network elements (that are the LAC and the LNS) MUST be equipped with the following functions: - admission control, a way to check resource availability and possibly refuse the request; - classification, a way to recognize the flow a frame belongs to; - policy enforcement, a way to ensure that the access network users are not using more resources than agreed; - scheduling, a way to treat frames according to contracts by means of prioritization. The Access Server knows the QoS parameters of the PVC that carry an incoming PPP session. In the upstream direction, the Access Server is able to determine the possibility of allocating (on the shared link) the resources required by the incoming PPP session. 2.3 Information Flow The Access Server MUST notify the Access Router with the QoS parameters of the PVC. In this way the Access Router will be able to allocate the necessary resources on the shared link for downstream traffic. In order to notify this information, there is the need to introduce new AVPs in the L2TP protocol for ICRQ messages. These new AVPs will contain the ATM PVC parameters (UBR, CBR, UBR-rt, UBR-nrt, etc.) that carry the PPP session. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 5] INTERNET DRAFT July 2000 2.4 QoS in underlying protocols The PPP protocol is in turn supported by: - the ATM protocol on the customer side; - the L2TP protocol on the ISP side. For a correct admission control procedure, the PPP Switch MUST be aware of the QoS characteristics of these underlying protocols. If either of the two is not QoS capable or provides insufficient QoS, the request cannot be admitted. We will assume that the L2TP is implemented over a QoS-capable network and that the tunnel has a static and known QoS. If this is the case, it is enough to insert in the PPP Switch information about tunnels QoS at configuration time. For the ATM part we have assumed a one-to-one correspondence between the PPP session and the ATM PVC. The PPP Switch will be aware of the QoS parameters of each PVC. 2.5 Other non-ATM Access Networks If the Access Network is a non-ATM network and QoS parameters cannot be inferred, the host MUST explicitly signal QoS parameters to the LAC. A way to signal those parameters SHOULD be the use of Fully Qualified Domain Names (FQDN) in the form of "username@qosparams.domain". 3.0 PPPoE This section will analyze the QoS problem for PPP in case the host is equipped with a PPPoE Client and the LAC is equipped with a PPPoE Server. 3.1 Network Model The reference circuit is the following: Fiaschi, Poggi, Rolandelli expires January 2001 [Page 6] INTERNET DRAFT July 2000 +------------+ +-----------+ | | +--------+ | | +--------+ +----+ | Ethernet | | Access | | Transport | | Access | |Host|----| Access |----| Server |----| Network |----| Router | +----+ | Network | | (LAC) | | | | (LNS) | | | +--------+ | | +--------+ +------------+ +-----------+ This network model is quite similar to the LAC one shown above (see Section 2.1). The main difference resides on the Access Network that in this model is Ethernet-based. Also in this model, hosts have to set up a PPP session with the selected Access Router, and the Access Server can be seen as a PPP Switch. As long as the Access Network is Ethernet-based (a shared architecture by definition), a proper method to adapt the PPP to this shared environment is needed and this is the PPPoE. With this protocol is possible to emulate a point to point connection over the Ethernet connectionless architecture. As in the LAC network model, the Transport Network multiplexes and tunnels all the PPP sessions for the same ISP over an L2TP tunnel. 3.2 QoS issues for PPPoE Server As between the Host and the LAC there is an Ethernet-based Access Network, a mechanism is needed to make the Ethernet network QoS enabled. This issue is discussed later in section 3.4. Between the LAC and the LNS the situation is identical to that described in section 2.2. 3.3 Information Flow Unlike the LAC model, for this case there is no way to deduce the desired QoS info from the underlying layers, hence this info MUST be explicitly signaled. There is a tag specified in RFC 2516 named Service_Name. It is used to specify the Services the Access Server can provide to the user. It can also include the QoS services offered to the user, e.g., in the form of Olympic Services (Gold, Silver and Bronze Services) or byte rates. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 7] INTERNET DRAFT July 2000 In the Discovery phase, the Access Server notifies to the user the available QoS classes and the user selects one of them. From now on, the Access Server will manage the traffic coming from that user with a queuing discipline defined for the class chosen. The PPP frames are policed and served as IP packets are managed in QoS-enabled routers: PPP sessions are multiplexed over tunnels towards ISPs in the same way as IP packets are multiplexed over data-link connections. From this point of view the PPPoE protocol serves as a signaling protocol such as the RSVP protocol serves as a signaling protocol at network layer. As in the LAC case, the Access Server MUST notify the Access Router with the QoS parameters signaled by the Host with the PPPoE protocol. In this way the Access Router will be able to allocate the necessary resources on the shared link for downstream traffic. In order to notify this information, there is the need to introduce new AVPs in the L2TP protocol for ICRQ messages. These new AVPs will contain the QoS parameters signaled by the Host. Both for the LAC case and for the PPPoE case, the semantic of these new AVPs will be consistent with RFC 2215 ("General characterization parameters for Integrated Services network elements") [5]. 3.4 QoS in underlying protocols The PPP protocol is in turn supported by: - the Ethernet protocol on the customer side; - the L2TP protocol on the ISP side. For a correct admission control procedure, the PPP Switch must be aware of the QoS characteristics of these underlying protocols. If either of the two is not QoS capable or provides insufficient QoS, the request cannot be admitted. We will assume that the L2TP is implemented over a QoS-capable network and that the tunnel has a static and known QoS. If this is the case, it is enough to insert in the PPP Switch information about tunnels QoS at configuration time. For the Ethernet part we must think more complex. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 8] INTERNET DRAFT July 2000 3.4.1 QoS-enabled Ethernet The IEEE 802.1p standard defines a set of priority levels that helps introduction of QoS in an Ethernet LAN. A priority scheme is unavoidable if traffic has to be scheduled over limited capacity interfaces. But a complete QoS system requires also admission and policy enforcement. If we consider that the critical part of the Ethernet LAN (extended up to the PPP switch) is the Customer Premises Network, one could avoid to deploy public admission and enforcement mechanisms to guarantee QoS parameters at the Ethernet layer. In fact we can assume the Ethernet portion that is shared among several customers to be located entirely inside the PPP Switch site and to support available band larger than the sum of the capacity needed by all the customers. This given, only the private portions of the Ethernet must be checked against unfair bandwidth allocation, but this is reasonably up to the owner of the resource. A more general scheme should include complete Ethernet QoS mechanisms to be developed. Inside IETF it is being standardized how an Ethernet switch must interpret the RSVP signaling in order to manage the bandwidth and provide QoS. This work led to the development of "A framework for providing Integrated Services over shared and switched IEEE 802 LAN technologies" [SBMFRAME] and to the definition of the "SBM (Subnet Bandwidth Manager): a protocol for RSVP-based admission control over IEEE 802-style networks" [SBMPROT] (Internet-Drafts of the Integrated Services over Specific Link Layers Working Group). In the reference model presented in the draft, the signaling information carried by RSVP is extracted and interpreted by every Ethernet switch it passes across. A new framework with similar characteristics is then needed if we want to preserve the QoS parameters contracted by means of PPPoE. The situation here could be simplified compared to native SBM, as we have a centralized control point (the PPPoE server). If we provide the PPPoE server with the knowledge of the entire Ethernet access network, it will have the possibility to exercise the Admission Control function during a PPPoE discovery phase. According to the required service, an appropriate IEEE 802.1p priority will be assigned to the service. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 9] INTERNET DRAFT July 2000 4.0 References [1] W. Simpson. "The Point-to-Point Protocol (PPP)", RFC 1661. July 1994. [2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. "Layer Two Tunneling Protocol (L2TP)". August 1999. [3] Y. T'Joens, P. Crivellari, B. Sales. "Layer Two Tunneling Protocol: ATM Access Network extensions", draft-ietf-l2tpext-atmext-02.txt. May 2000. [4] S. Blake, T. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. "An Architecture for Differentiated Services". December 1998. [5] S. Shenker, J. Wroclawski. "General characterization parameters for Integrated Services network elements". September 1997. [6] R. Braden, L. Zang, S. Berson, S. Herzog, S. Jamin. "Resource ReSerVation Protocol (RSVP)". September 1997. 5.0 Acknowledgements This Draft has been largely inspired from an unpublished paper written by Mauro Filippi (Marconi Services), Sergio Torassa (Infostrada) and Giovanni Fiaschi (Marconi Communications). The Authors would also like to acknowledge Diego Caviglia (Marconi Communications) and Luca Patrone (Marconi Communications) for their contributions to this Draft. Fiaschi, Poggi, Rolandelli expires January 2001 [Page 10] INTERNET DRAFT July 2000 6.0 Authors' Addresses Questions about this memo can be directed to: Giovanni Fiaschi Marconi Marconi Communications S.p.A. Via A. Negrone, 1/A 16153 GENOVA, ITALY Phone: +39.10.6003583 Fax: +39.10.6003849 E-mail: giovanni.fiaschi@marconi.com GianLuca Rolandelli Marconi Marconi Communications S.p.A. Via A. Negrone, 1/A 16153 GENOVA, ITALY Phone: +39.10.6003540 Fax: +39.10.6003849 E-mail: gianluca.rolandelli@marconi.com Fabio Poggi Marconi Marconi Communications S.p.A. Via A. Negrone, 1/A 16153 GENOVA, ITALY Phone: +39.10.6003586 Fax: +39.10.6003849 E-mail: fabio.poggi@marconi.com Fiaschi, Poggi, Rolandelli expires January 2001 [Page 11]