Network Working Group Abel Wang Category: Internet-Draft Wenxiu Xu Yanqing Lu Lei Cao Rong Zhang Tao Zhang Maowen Guo Category: Informational October 2003 Virtual Broadband Access Server Protocol for communicating between BAS and IP-DSLAM draft-abel-vbas-01.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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The virtual broadband access server (VBAS) protocol looks BAS and IP-DSLAM as a whole and provides an applicable method for communicating between BAS and IP-DSLAM. This document describes a communication process, which is added in the existing access control modes. It also describes how to encapsulate VBAS packets over Ethernet. Applicability This specification is intended to provide the facilities, which are defined for VBAS. Wang/Xu/Lu/Cao [Page 2] VBAS Protocol Oct 2003 This specification can support ADSL or VDSL or LAN access modes that use IP uplink. It is independent of authentication mode. This document describes the VBAS over Ethernet encapsulation that is being deployed by China Telecom-Guangzhou Research and Development Center. 1 Introduction DSL technologies, which use twisted pairs as transport medium, are the dominant broadband technologies for subscribers to access broadband services. Broadband deployment has focused on DSLAM in the past two years. Traditional uplink interface of DSLAM is ATM that is suitable for telecom service providers who have the ATM metropolitan area networks. With the DSLAM construction increasing, the ATM resource is limited and being exhausted. As a result, the new metropolitan area networks are based on Ethernet and IP-DSLAM is introduced for DSLAM to link Ethernet metropolitan area networks. Switches are used between IP-DSLAM and BAS as aggregation network, whose VLAN ID is limited (vary from 0 to 4095). Subscribers must share a VLAN and the subscribers¨Æ detailed information can¨Æt be sent to the BAS and Radius server. Many issues, such as tracking of hackers and security of subscribers etc, emerged in the use of IP-DSLAM. VBAS protocol adds a communication process between BAS and IP-DSLAM, which can get the subscribers¨Æ detailed information of physical address. 2 Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [1]. 3 Protocol Overview There are three access control modes for IP-uplink ADSL subscribers: PPPOE¨802.1X and DHCP+WEB. Below PPPOE is used for example. In order to resolving the problems introduced by IP-DSLAM, VBAS protocol”ĄVirtual Broadband Access Server”æis submitted. That is, a communication process is added between an IP-DSLAM and a BAS in the existing authentication process. After a BAS sends a PADS packet of PPPOE to a new subscriber, it will query the IP-DSLAM about the physical-port information which corresponding to the MAC-address of the new subscriber. When the IP-DSLAM gets the VBAS Query packet, it will respond a VBAS Response packet, which includes the physical-port information. Wang/Xu/Lu/Cao [Page 3] VBAS Protocol Oct 2003 To avoid broadcast packets between BAS and IP-DSLAM in network, the communication process is point to point between a BAS and an IP-DSLAM in MAC layer. 4 Payloads The following packet formats are defined here. The payload contents will be defined in the VBAS sections. An Ethernet frame is as follows: 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DESTINATION_ADDR | | (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SOURCE_ADDR | | (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ payload ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The DESTINATION_ADDR field contains a unicast Ethernet destination address. The SOURCE_ADDR field MUST contain the Ethernet MAC address of the source device. The ETHER_TYPE is set to 0x8200 (suggested for VBAS). The Ethernet payload for VBAS is as follows: Wang/Xu/Lu/Cao [Page 4] VBAS Protocol Oct 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER | Reserved Field 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transferred info Type | Operation Type|Operation Result| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VBAS Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Hardware Address length|Information length|Hardware Interface Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Hardware Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Hardware Address | Source Vlan ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Hardware Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Hardware Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Vlan ID | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |User Port Info Length| User Port Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ User Port Information ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VER field is eight bits and MUST be set to 0x1 for this version of the VBAS specification. The Reserved field 1 is twenty-four bits and MUST be set to 0x000 for this version of the VBAS specification. The Transferred info Type field is sixteen bits and MUST be set to 0x01 for this version of the VBAS specification. A value of 0xff MUST NOT be used. The Operation Type field is eight bits and defined below for VBAS Query and Response stage. The Operation Result field is eight bits and defined below for VBAS Query and Response stage. The VBAS Session ID field is thirty-two bits. It is an unsigned value in network byte order. Its value is defined below for VBAS Query packets. The value is fixed for a given VBAS session and, in fact, defines a VBAS session along with the Ethernet SOURCE_ADDR and DESTINATION_ADDR. A value of 0xffff is reserved for future use and MUST NOT be used. The Hardware Address Length field is eight bits and MUST be set to 0x6 that refers to the MAC address length for this version of the VBAS specification. Wang/Xu/Lu/Cao [Page 5] VBAS Protocol Oct 2003 The Information Length field is eight bits and MUST be set to 0x4 for this version of the VBAS specification. The Hardware Interface Type field is sixteen bits and defined below for VBAS Query and Response stage. The Source Hardware Address field is forty-eight bits and defined below for VBAS Query and Response stage. The Source VLAN ID field is sixteen bits and defined below for VBAS Query and Response stage. The Source Port field is sixteen bits and MUST be set to ox00 for this version of the VBAS specification. The Destination Hardware Address field is forty-eight bits and defined below for VBAS Query and Response stage. The Destination VLAN ID field is sixteen bits and MUST be set the same value as Source VLAN ID field. The Destination Port field is sixteen bits and MUST be set to ox00 for this version of the VBAS specification. The User Port Info Length field is eight bits and defined below for VBAS Query and Response stage. The User Port Information field is no more tran 127 bytes and defined below for VBAS Query and Response stage. 5.VBAS protocol There are two stages in VBAS protocol. When it completes, BAS can get the physical address of a new subscriber. First step is VBAS Query; second step is VBAS Response. All VBAS Ethernet frames are suggested to have the ETHER_TYPE field set to the value 0x8200. The VBAS communication process is shown in Figure 1, below. PC IP-DSLAM BAS |------------------------------------|----------------------| | PPPOE Discovery Stage | |------------------------------------|----------------------| | VBAS Query Stage | |<---------------------| | VBAS Response Stage | |--------------------->| | PPPOE Session Stage | |-----------------------------------------------------------| Figure 1 VBAS communication process Wang/Xu/Lu/Cao [Page 6] VBAS Protocol Oct 2003 5.1 The VBAS Query Packet After a BAS send a PADS packet of PPPOE to a new subscriber, it will prepare to begin a VBAS session. It generates a unique SESSION_ID for the VBAS session and sends the VBAS Query Packet to an IP-DSLAM about the physical-port information which corresponding to the MAC address of the new subscriber. The Operation Type field MUST be set to 0x1 that indicates it is the VBAS query operation. The Operation Result field MUST be set to 0x0. The Hardware Interface field MUST be set to 0x0.The Source Hardware Address is the MAC address of BAS. The Destination Hardware Address is the MAC address of the new subscriber. If the packet received in PADR stage of PPPOE is untagged, the Source Vlan ID field MUST be set to 0xFFFF; If the packet received in PADR stage of PPPOE is tagged, the Source VLAN ID field is the same value as it in PADR packet of PPPOE. The User Port Information Length field and the User Port Information field in the VBAS Query stage is not available. 5.2 The VBAS Response Packet When an IP-DSLAM gets the VBAS Query packet, it will send a VBAS Response Packet to the BAS, which includes the physical-port information of the new subscriber. The Operation Type field MUST be set to 0x2 that indicates it is the VBAS response operation. The Operation Result field MUST be set to 0x0 for successful request and 0x1 for failure. The VBAS Session ID MUST be set the value as it in VBAS Query packet. The Hardware Interface field MUST be set to 0x10 for DSL subscriber, which is same as the value of NAS-Port-Type defined in RFC 2865. The Source Hardware Address is the MAC address of the new subscriber. The Destination Hardware Address is the MAC address of BAS. The Destination Vlan ID field is the same value of the Source VLAN ID field. The Source VLAN ID field is valid in low 12 bits and contains the physical-port information of the new subscriber. It is transported from BAS to RADIUS Server. If the Source VLAN ID can accurately identify the DSLAM port such as slot number, subslot number and port number,the value of the User Port Info Length field is 0 and the User Port Information field does not exist. Otherwise,the User Port Information field must be included in the VBAS Response Packet and its length will be filled in the User Port Information Length field. The reference format of the User Port Information field is as follows: "frame=0~31; slot=0~63; port=0~127;" 6 Other Considerations When a BAS does not receive a VBAS Repose packet within a specified amount of time, it SHOULD resend its VBAS Query packet and double the waiting period. This is repeated many times as desired; otherwise the VBAS Query is failed. A BAS MUST receives a VBAS Response packet before it began to send an authentication access packet to Radius Server; otherwise the VBAS Query is failed. Wang/Xu/Lu/Cao [Page 7] VBAS Protocol Oct 2003 7 Security considerations 8 Acknowledgments This document is based on concepts discussed in our team. 9 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [3] L. Mamakos, Editor, ¨˙A Method for Transmitting PPP Over Ethernet (PPPoE)¨˙, RFC 2516, February 1999 10 Authors¨Æ Addresses Abel Wang China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: wangab@gsta.com Wenxiu Xu China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: xuwx@gsta.com Yanqing Lu China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: luyq@gsta.com Lei Cao Guangdong Telecom TianHe District, Guangzhou China Email: cao@spring.gd.cn Wang/Xu/Lu/Cao [Page 8] VBAS Protocol Oct 2003 Rong Zhang China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: zhangr@gsta.com Tao Zhang China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: zhangt@gsta.com Maowen Guo China Telecom-Guangzhou Research and Development Center 109 ZhongShan Ave TianHe District, Guangzhou China Email: guomw@gsta.com 11 Glossary ADSL Asymmetric Digital Subscriber Line ATM Asynchronous Transport Mode BAS Broadband Access Server DHCP Dynamic Host Configuration Protocol DSLAM Digital Subscriber Line Access Multiplexer IMA Inverse Multiplexing for ATM IP Internet Protocol LAN Local Area Network MAC Media Access Control PADS PPPoE Active Discovery Session-confirmation PPPOE PPP Over Ethernet ID Identification RADIUS Remote Authorization Dial In User Service STM Synchronous Transport Mode VBAS Virtual BAS VDSL Very-high-speed Digital Subscriber Line VLAN Virtual LAN 12 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. Wang/Xu/Lu/Cao [Page 9] VBAS Protocol Oct 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.