PPP Extensions Working Group Avri Doria Internet Draft Xing Chen Expires 30 Sep. 1997 General DataComm 25 March 1997 Proposal for a PPP Network Layer Entity Selection Protocol Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Inter- net Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract With the introduction of xDSL services into public telecommunica- tions networks, direct access (in contrast to dial-up access) will start to be used as an access method for data as well as other services. PPP has been very successful in providing connections for IP as well as other protocols in the dial-up access network. With the advent of direct access, changes will be need to be made for identifying the target hosts, as it will no longer be possible to rely on the telephone number that is dialed prior to initiating the PPP session. This proposal indicates one method for adapting PPP to the new requirements. Internet Draft PPP Network Layer Entity Selection March 1997 1. Overview Whether it is for business reasons, or, in the US, because of the Telecommunications Act of 1996, local exchange carriers (LECs), competitive access providers (CAPs) and Internet service providers (ISPs) are all vying for the same markets. Many of the proposed access models include shifting away from POTS (plain old telephone service) to xDSL. This will allow the LECs to offer high end broadband access, with at least partial PPP termination, in the central office with trunking of IP and other traffic over ATM, Frame Relay or Sonet connections. Currently there are two ways to provide PPP access in a direct access network; by using hard wired connections or by using hard state connections. Both of these are unsatisfactory solutions, however, and the LECs are already searching for equipment which allows a direct access customer to switch service providers without needing to also change a hard provisioning. The normal procedure in PPP, is for the PPP termination point to be identified prior to making the connection; for example, the phone number is dialed, or the DLCI is assigned. In a direct access scenario, the customers will have a permanent connection to the central office where the copper loop is terminated. There is currently no means of dynamically defining the service provider prior to making a connection. Several different scenarios were investigated: (1) Add a protocol before LCP to define the service provider requested. This was rejected because the nature of the connection will not change when switching from one service provider to another. While running the LCP connection phase may not be that expensive, it did seem like a a wasted step. Addition- ally, this would require another protocol which did not seem to fit in the PPP model. Doria & Chen Exp. 30 Sep. 1997 [Page 2] Internet Draft PPP Network Layer Entity Selection March 1997 (2) Add the system identification information to the RADIUS pro- tocol. This was considered, but rejected because of the essential nature of the decision being made. The system to be accessed must be defined before the correct network access server can be selected. It was suggested that the system identifier could be included in one of the RADIUS protocol fields. This becomes difficult when we start to consider different types of addressing that might be used; for example, IP addressing, E.164 addressing, NANP addressing (telephone numbers as in the dial-up case). These have differing forms and lengths and will need to be identified in any protocol used to carry them. (3) Add the target service to the authentication name when using L2TP. This was rejected for similar reasons to those outlined above. It was also rejected because a general mechanism is required, that is, one which does not require tunneling. It is very possible that the LECs will be offering virtual col- location services which use the RADIUS model for authentica- tion and accounting. In this case a model which relies on tunneling would not be effective. (4) Include a connection phase LCP option to identify the ser- vice provider desired. It was suggested that this could either be defined as a standard or as a proprietary solution. This was rejected for several reasons. Partially it was for the same reason suggested above, the connection will not change and there is no reason to renegotiate a connection that is already established. Additionally, it is felt that this may not be an appropriate task for a link establishment phase. Finally, it was felt that this service would be too wide spread for a vendor specific solution. Doria & Chen Exp. 30 Sep. 1997 [Page 3] Internet Draft PPP Network Layer Entity Selection March 1997 For the reasons outlined above, this draft proposes a new LCP pro- tocol which can be optionally run after the LCP connection phase has completed, but before any authentication protocols are run. This Network Layer Entity Selection Protocol (NLES) is defined in this draft. 2. Description of NLES After the LCP has completed but before any of the authentication protocols were run, the NLES will be run. This would be PPP proto- col number cXXX (a number has yet to be applied for from IANA). The message format will be as follows. It follows the Internet Protocol convention for packet description. 2.1. NLES Packet format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Address Type | Address Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2.2. NLES Codes The PPP NLES protocol will support 4 message codes. Code Function 1 NLES-Request 2 NLES-Ack 3 NLES-Nak 4 NLES-Reject Doria & Chen Exp. 30 Sep. 1997 [Page 4] Internet Draft PPP Network Layer Entity Selection March 1997 Code 1 In the NLES request, the sender would declare the addressing mode to be used and request a certain address. The reply could be: Code 2 In this case, the original message would be returned with the code changed to indicate success. Code 3 In this case, the message would be changed to include a pre- ferred address type and address. This type of message could be used to do a query of a service provider if that service provider wished to provide service on different servers depending on some particular policy. Code 4 In this case the message would be returned with the code changed to indicate failure. 2.3. NLES Address Types The PPP NLES address types are: Type Description Size 1 E.164 encoded in BCD format 8 2 NANP - North American Number Plan 5 3 IP Version 4 4 4 IP Version 6 16 3. Security Considerations Security issues are not considered in this draft. Doria & Chen Exp. 30 Sep. 1997 [Page 5] Internet Draft PPP Network Layer Entity Selection March 1997 4. References TBD 5. Contacts Chair's Address The working group can be contacted via the current chair: Karl F. Fox Ascend Communications 3518 Riverside Dr., Suite 101 Columbus, OH USA 43221 Authors' Addresses Questions about this draft can be directed to: Avri Doria Boston Research Center General DataComm Inc. 5 Mount Royal Ave Marlborough MA USA 01752 (508) 624 6723 avri@gdc.com Xing Chen Technology Research Center General DataComm Inc Park Road Extension P.O. Box 1299 Middlebury, CT 06762-1299 (203) 758 1811 xchen@gdc.com Doria & Chen Exp. 30 Sep. 1997 [Page 6] Internet Draft PPP Network Layer Entity Selection March 1997 Doria & Chen Exp. 30 Sep. 1997 [Page 7]