Network Working Group T. Matsuda Internet-Draft Mitsubishi Electric Corporation March 2004 Signaling Protocol for Access Service Network using LDP draft-matsuda-l2vpn-access-service-protocol-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. Abstract Access Service Network is a Network Access Provider's network. In Access Service Network, subscribers can connect to various ISPs/VPNs by specifying appropriate authentication information. This draft describes a signaling protocol based on PWE3 control protocol [PWE3- SIG] for Access Service Network which uses IEEE 802.1x as a user authentication protocol. The protocol sets up a special kind of VPLS which does not forward broadcast/multicast Ethernet frames between subscribers for better security. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Matsuda Expires September 2004 [Page 1] Internet-Draft Signaling for Access Service Network March 2004 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 RFC-2119 [i]. 1. Introduction Access Service Network is a Network Access Provider's network. In Access Service Network, subscribers can connect to various ISPs/VPNs by specifying appropriate authentication information. To implement Access Service Network, PPPoE and L2TP are widely deployed. With L2TP, user packet data are transported with PPP header, L2TP header, UDP header and IP header (38 bytes in total) added. In this draft, we propose a protocol in which user authentication is done with IEEE 802.1x and user Ethernet frames are transported over pseudo wires (PWs) realized by MPLS label stacking, thus reducing the overhead. A pseudo wire is set up between a Network Access Concentrator (NAC) accommodating subscribers and a Network Server (NS) accommodating ISPs/VPNs using Generalized ID FEC Element defined in [PWE3-SIG]. A bridge module exists only in NS and it forwards Ethernet frames between Attachment Circuit (AC) connected to an ISP/VPN and PWs. A bridge module in NS does not forward broadcast/multicast Ethernet frames between PWs for better security (preventing broadcast flooding, enabling ISP/VPN CE to control IP packet between subscribers, etc.). We need to define a Generaliezed ID FEC format for Access Service Network application because of this special forwarding behavior of the bridge module in a NS. A Label Mapping message used to establish a PW can include a TLV specifying minimum guaranteed bandwidth between a subscriber and an ISP/VPN for each direction. NAC uses RADIUS protocol [RADIUS], [RAD- TNL] to discover NS. 2. Network Model In this section, we describe the network elememts comprising an Access Service Network. Figure 1 and Figure 2 depict the network model. Matsuda Expires September 2004 [Page 2] Internet-Draft Signaling for Access Service Network March 2004 +--------+ +--------+ | RADIUS | | RADIUS | | Server | | Server | +--------+ +--------+ +----------+ \ | \ |Subscriber| +-----+ | +----+ +--------+ | CE |--| NAC |----------------| NS |-----|ISP/VPN | +----------+ +-----+ | +----+ | CE | \ \ +--------+ +----------+ +-----+ \ \ |Subscriber|--| NAC |-------------- | CE | +-----+ +----------+ | | |<-- Access Service Network -->|<-- ISP or VPN Figure 1 AC PW NS AC | NAC | +------------+ | v +-------+ v | +--------+ | | Subscriber -----|--<>---|--------|-| bridge | | v CE | | | | module |-|----- ISP/VPN -----|--<>---|--------|-| | | +-------+ | +--------+ | +------------+ Figure 2 - Access Service Network : Access Service Network is a network where subscribers can be connected to various ISPs/VPNs depending on the authentication information presented by the subscribers. - NAC (Network Access Concentrator) : A provider edge router which has interfaces to accommodate subscribers. NAC queries RADIUS server in Access Service Network about NS with which a pair of pseudo wires needs to be established using authentication information provided by a subscriber. NAC corresponds to LAC in L2TP. - NS (Network Server): A provider edge router which has interfaces to accommodate ISPs/VPNs to which subscribers connect. NS acts as a proxy RADIUS server for NAC in subscriber authentication and transfers RAIDUS requests/responses between NAC and RADIUS server in ISP/VPN. NS corresponds to LNS in L2TP. Matsuda Expires September 2004 [Page 3] Internet-Draft Signaling for Access Service Network March 2004 - Subscriber CE : Subscriber CE is a terminal or a network equipment owned by a subscriber and it is connected to NAC. A subscriber is connected to Access Service Network through Subscriber CE. By specifying which ISP/VPN to connect to with subscriber authentication information, Subscriber CE can connect to various ISPs/VPNs through Access Service Network. Subscriber CE runs IEEE 802.1x as an authentication protocol with NAC when connecting to NAC. - ISP/VPN CE : ISP/VPN CE is a network equipment owned by an ISP/VPN and it is connected to NS. ISP/VPN is connected to Access Service Network through ISP/VPN CE. - RADIUS Server in Access Service Network : This RADIUS server helps NAC discover NS to which a pair of PWs needs to be set up. When NAC sends Access-Request message to a RADIUS server in Access Service Network, the RADIUS server in Access Service Network returns the information about NS to which a pair of PWs needs to be set up. - RADIUS Server in ISP/VPN : RADIUS server in ISP/VPN acts as a RADIUS server for NS in subscriber authentication. It determines whether a subscriber should be allowed to access the ISP/VPN depending on the information sent by NAC through NS. 3. Connection setup/release procedure between subscriber CE and ISP/VPN CE In Access Service Network, a connection between Subscriber CE and ISP/VPN is established in the following three stages. (1) NS discovery by NAC (2) Subscriber CE authentication by NAC (3) Pseudo Wire setup/release between NAC and NS We will describe those stages. 3.1 NS discovery by NAC In this section, we describe how NAC finds NS to which a pair of PWs needs to be set up using authentication information provided by a Subscriber CE in connecting to NAC. When a Subscriber CE tries to connect to NAC using IEEE 802.1x as an authentication protocol, NAC must discover NS which acts as a Matsuda Expires September 2004 [Page 4] Internet-Draft Signaling for Access Service Network March 2004 proxy RADIUS server in subscriber authentication and to which a pair of PWs needs to be established first. For that purpose, NAC sends RADIUS Access-Request message including User-Name AVP the value of which is subscriber identifier provided by Subscriber CE to a RADIUS server in Access Service Network. Using value field of User-Name AVP in Access-Request message, RADIUS server in Access Service Network resolves NS which acts as a proxy RADIUS server in subscriber authentication and to which a pair of PWs needs to be established. If resolved successfully, RADIUS server in Access Service Network returns Access-Accept message with Tunnel-Medium-Type AVP and Tunnel-Server-Endpoint AVP indicating NS address to NAC. If failed in resolving, RADIUS server in Access Service Network returns Access-Reject message to NAC. 3.2 Subscriber CE authentication by NAC In this section, we describe how NAC authenticates a Subscriber CE in connecting to NAC. After discovering NS, NAC exchanges RADIUS messages with NS which acts as a proxy RADIUS server to authenticate a Subscriber CE. As a proxy RADIUS server, NS transfers Access-Request message received from NAC to an appropriate RADIUS server in ISP/VPN determined by the value field of User-Name AVP in Access-Request message indicating the subscriber identity. Minimum guaranteed bandwidth between Subscriber CE and ISP/VPN CE for each direction may be indicated in Vendor Specific AVP included in Access-Accept message returned by a RADIUS server in ISP/VPN. The format of the Vendor Specific AVP is defined in 4.2. NAC proceeds to establish a pair of PWs with NS if NS returns Access-Accept message, which means that a subscriber authentication succeeded. NAC refuses to establish a connection with a Subscriber CE if NS returns Access-Reject message, which means that the subscriber authentication failed. 3.3 Pseudo Wire setup procedure between NAC and NS In this section, we describe how NAC sets up a pair of PWs with NS. If NAC finds that it has sufficient resource to establish a PW with NS for packet transport from Subscriber CE to ISP/VPN CE, NAC sends a LDP Label Mapping message with Generalized ID FEC Element TLV representing a connection between NAC and a Subscriber CE. Label Mapping message may include Vendor Specific TLV indicating minimum guaranteed bandwidth between Subscriber CE and ISP/VPN CE for each direction if necessary. We describe the format of Generalized ID FEC Element and Vendor Specific TLV in 4.1. NAC establishes a LDP session with NS before sending Label Mapping message if one is not Matsuda Expires September 2004 [Page 5] Internet-Draft Signaling for Access Service Network March 2004 established. NAC also establishes an LSP with NAC as ingress LSR and NS as egress LSR if necessary. On receiving a Label Mapping message from NAC, NS checks if it has sufficient resource to establish a PW with NAC for packet transport from ISP/VPN CE to Subscriber CE. If it has, NS sends a Label Mapping message with Generalized ID FEC Element TLV SAII and TAII of which are the reverse of those in Generalized ID FEC Element TLV received from NAC. If it does not, NS sends a Label Release message to NAC. When NAC receives a Label Mapping message, it searches for a Subscriber CE corresponding to Generalized ID FEC Element TLV in the Label Mapping message and finish establishing a connection with the Subscriber CE. If NAC can not find the corresponding Subscriber CE, NAC sends a Label Release message to the originating NS. When NAC receives a Label Release message, it searches for a Subscriber CE corresponding to Generalized ID FEC Element TLV in the Label Release message and refuses to establish a connection to the Subscriber CE. 3.4 Pseudo Wire Tear Down Procedure When a connection between a Subscriber CE and NAC is broken for some reason, NAC sends a Label Withdraw message to NS. On receiving a Label Withdraw message, NS searches for a PW with Generalized ID FEC Element TLV SAII and TAII of which are the reverse of those in Generalized ID FEC Element TLV received from NAC. If a PW is found, NS sends a Label Withdraw mesasge for the FEC and tears down the PW. If NS desires to tear down a pair of PWs, NS sends a Label Withdraw messsage to NAC. On receiving a Label Withdraw message, NAC searches for a PW for Generalized ID FEC Element TLV SAII and TAII of which are the reverse of those in Generalized ID FEC Element TLV received from NS. If a PW is found, NAC sends a Label Withdraw mesasge for the FEC and tears down the PW. 4. Protocol Message Format 4.1 LDP related message format 4.1.1 Generalized ID FEC Element format for Access Service Network Application Type filed value of SAII and TAII and PW type field value for this appplication is to be assinged by IANA. Generalized ID FEC Element is defined in [PWE3-SIG]. In this draft, AGI field of Generalized ID FEC Element is not used. We describe the format of SAII and TAII in the following. - value field of SAII for Generalized ID FEC Element in Label Mapping Matsuda Expires September 2004 [Page 6] Internet-Draft Signaling for Access Service Network March 2004 message from NAC to NS and TAII for Generalized ID FEC Element in Label Mapping message from NS to NAC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID of NAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID between Subscriber CE and NAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"Router ID of NAC" is a 4 octet identifier of NAC unique in Access Service Network. *"Connection ID between Subscriber CE and NAC" is an identifier which contains enough information for NAC to identify Subscriber CE (e.g. interface index to which Subscriber CE is connected case). The value of "Connection ID between Subscriber CE and NAC" is only meaningful to NAC and is of local significance. The length of "Connection ID between Subscriber CE and NAC" can be determined by subtracting 4 from Length field value of SAII. - value field of TAII for Generalized ID FEC Element in Label Mapping message from NAC to NS and SAII for Generalized ID FEC Element in Label Mapping message from NS to NAC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISP/VPN identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"ISP/VPN identifier" is an identifier of ISP/VPN to which a Subscriber CE is trying to connect. We assume that NAC can obtain the value of "ISP/VPN identifier" from subscriber identifer presented by the Subscriber CE when authenticating it and NS can identify ISP/VPN from "ISP/VPN identifier" using configuration information. For example, if the subscriber identifier is the form of Network Access Identifier (NAI) (e.g. user_id@isp_domain_name), isp_domain_name string can be used as "ISP/VPN identifier". 4.1.2 Vendor Specific TLV format In this section, we describe the format of Vendor Specific TLV [LDP] used to carry information on QoS parameter for the PW between Subscriber CE and ISP/VPN CE. Matsuda Expires September 2004 [Page 7] Internet-Draft Signaling for Access Service Network March 2004 - U flag=1, F flag=1, Type=0x3E00 - Vendor ID Vendor ID of Vendor Specific TLV used is that of Mitsubishi Electric Corporation. - Data 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Guaranteed Bandwidth from Subscriber to ISP/VPN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Guaranteed Bandwidth from ISP/VPN to Subscriber | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"Minimum Guaranteed Bandwidth from Subscriber to ISP/VPN" indicates the minimum guaranteed bandwidth from Subscriber to ISP/VPN in byte/sec. This field is encoded as a 32-bit IEEE single-precision floating-point number. *"Minimum Guaranteed Bandwidth from ISP/VPN to Subscriber" indicates the minimum guaranteed bandwidth from ISP/VPN to Subscriber in byte/sec. This field is encoded as a 32-bit IEEE single-precision floating-point number. 4.2 RADIUS related message format We describe the format of RADIUS Vendor Specific AVP [RADIUS] used in this draft. This AVP indicates the minimum guaranteed bandwidth for PW between Subscriber CE and ISP/VPN CE. - Vendor-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of Mitsubishi Electric Corporation. - String "String filed" is structured as a sub-AVP. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor Type | Vendor Length | Minimum Guaranteed Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | from Subscriber to ISP/VPN | Minimum Guaranteed Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | from ISP/VPN to Subscriber | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Matsuda Expires September 2004 [Page 8] Internet-Draft Signaling for Access Service Network March 2004 *"Vendor Type" = 1. *"Vendor Length" = 8. *"Minimum Guaranteed Bandwidth from Subscriber to ISP/VPN" indicates the minimum guaranteed bandwidth from Subscriber to ISP/VPN in byte/sec. This field is encoded as a 32-bit IEEE single-precision floating-point number. *"Minimum Guaranteed Bandwidth from ISP/VPN to Subscriber" indicates the minimum guaranteed bandwidth from ISP/VPN to Subscriber in byte/sec. This field is encoded as a 32-bit IEEE single-precision floating-point number. Defining a format which is similar to Traffic Parameter TLV defined by CR-LDP and can convey QoS related information is for further study. 5. Security Considerations The usage of LDP and RADIUS protocols in this draft does not improve nor worsen the security problems related to LDP and RADIUS. 6. IANA Considerations Type field value of SAII and TAII and PW type field value in Generalized ID FEC for this appplication needs to be assigned by IANA. 7. References [PWE3-SIG] L. Martini, E. Rosen, N. Wl-Aawar, T. Smith and G. Heron, "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-05.txt, work in progress. [RADIUS] C. Rigney, S. Willens, A. Rubens and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", rfc2865, June 2000. [RAD-TNL] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", rfc2868, June 2000. [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette and B. Thomas, "LDP Specification", Matsuda Expires September 2004 [Page 9] Internet-Draft Signaling for Access Service Network March 2004 rfc3036, January 2001. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgements We thank Shuji Ito, Mitsuru Tsuchida and Keiji Okubo for their comments on the ideas presented in this draft. 10. Authors' Addresses Tetsushi Matsuda Mitsubishi Electric Corporation. 5-1-1, Ofuna, Kamakura-shi, Kanagawa-ken, 24 Japan Phone: +81 467 41 2869 FAX: +81 467 41 2819 EMail: tmatsuda@isl.melco.co.jp Matsuda Expires September 2004 [Page 10]