Network Working Group Internet-Draft T. Matsuda Expires: August 2004 Mitsubishi Electric Corporation Category: Informational February 2004 Signaling Protocol for Access Service Network using LDP draft-matsuda-l2vpn-access-service-protocol-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 Access Service Network is a network where subscribers can be connected to various ISPs/VPNs depending on the authentication inforamtion presented by the subscribers. This draft describes a signaling protocol based on PWE3 control protocol [PWE3-SIG] for Access Service Network. The protocol makes it possible to set up a pair of pseudo wires between a subscriber and an ISP/VPN with minimum guaranteed bandwidth in Access Service Network. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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]. MATSUDA Expires August 2004 [Page 1] Internet-Draft Signaling for Access Service Network February 2004 1. Introduction Access Service Network is a network where subscribers can be connected to various ISPs/VPNs depending on the authentication inforamtion presented by the subscribers. To implement Access Service Network, L2TP is 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 packet data are transported over pseudo wires 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] in the proposed protocol. A Label Mapping message used to establish a pseudo wire can include a TLV specifing minimum guaranteed bandwidth between a subscriber and an ISP/VPN for each direction. NAC uses RADIUS protocol [RADIUS], [RAD-TNL] to discover NS. The protocol described in this draft can be used to implement Ethernet access service authenticating a subscriber by 801.X and IP access service authenticating a subscriber by PPPoE. 2. Network Model In this section, we describe the network elememts comprising an Access Service Network. Figure 1 depicts the network model. +--------+ +--------+ | RADIUS | | RADIUS | | Server | | Server | +--------+ +--------+ +----------+ \ | \ |Subscriber| +-----+ | +----+ +--------+ | CE |--| NAC |----------------| NS |-----|ISP/VPN | +----------+ +-----+ | +----+ | CE | \ \ +--------+ +----------+ +-----+ \ \ |Subscriber|--| NAC |-------------- | CE | +-----+ +----------+ | | |<-- Access Service Network -->|<-- ISP or VPN Fig.1 Network Model of Access Service Network - Access Service Network : Access Service Network is a network where subscribers can be connected to various ISPs/VPNs depending on the authentication inforamtion presented by the subscribers. MATSUDA Expires August 2004 [Page 2] Internet-Draft Signaling for Access Service Network February 2004 - 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. - 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 some authentication protocol such as PPPoE and 802.1X 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 pseudo wires 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 pseudo wires 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. MATSUDA Expires August 2004 [Page 3] Internet-Draft Signaling for Access Service Network February 2004 3.1 NS discovery by NAC In this section, we describe how NAC finds NS to which a pair of pseudo wires needs to be set up using authentication informatino provided by a Subscriber CE in connecting to NAC. When a Subscriber CE tries to connect to NAC using an authentication protocol such as 802.1X and PPPoE, NAC must discover NS which acts as a proxy RADIUS server in subscriber authentication and to which a pair of pseudo wires 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 pseudo wires 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 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. Consider the case where Access Service Network is an IP access service network and needs to assign an IP address prefix to a Subscriber CE. If a RADIUS server in ISP/VPN requests the RADIUS client to assign an IP address from its address pool by including Framed-Pool AVP or Framed-IPv6-Pool AVP in Access-Accept message, NS assigns one from an address pool configured in itself and replaces Framed-Pool AVP or Framed-IPv6-Pool AVP with Framed-IP- Address or Framed-IPv6-Prefix AVP and transfers Access-Accept message to NAC. Minimum guaranteed bandwidth between Subscriber CE and ISP/VPN CE for each direction is 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.1. NAC proceeds to establish a pair pseudo wires 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. MATSUDA Expires August 2004 [Page 4] Internet-Draft Signaling for Access Service Network February 2004 3.3 Pseudo Wire setup procedure between NAC and NS In this section, we describe how NAC sets up a pair of pseudo wires with NS. If NAC finds that it can satisfy the minimum guaranteed bandwidth requirement for packet transport from Subscriber CE to ISP/VPN CE, NAC sends a LDP Label Mapping message with Generalized FEC ID Element TLV representing a connection between NAC and a Subscriber CE. Label Mapping message includes Vendor Specific TLV indicating minimum guaranteed bandwidth between Subscriber CE and ISP/VPN CE for each direction. We describe the format of Generalized FEC ID Element and Vendor Specific TLV in 4.2. NAC establishes a LDP session before sending Label Mapping message if one is not established. NAC also establishes an LSP with NAC as ingress LSR and NS as egress LSR if necessary. If NAC finds that it can not satisfy the minimum guaranteed bandwidth requirement for packet transport from Subscriber CE to ISP/VPN CE, NAC refuses to establish a connection to a Subscriber CE. On receiving a Label Mapping message from NAC, NS checks if it can satisfy the minimum guaranteed bandwidth requirement for packet transport from ISP/VPN CE to Subscriber CE. If it can, NS sends a Label Mapping message with Generalized FEC ID Element TLV SAII and TAII of which are the reverse of those in Generalized FEC ID Element TLV received from NAC. If it can 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 FEC ID 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 FEC ID Element TLV in the Label Release message and refuses to establish a connection to a 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 LSP for Generalized FEC ID Element TLV SAII and TAII of which are the reverse of those in Generalized FEC ID Element TLV received from NAC. If a LSP is found, NS sends a Label Withdraw mesasge for the FEC and tears down the LSP. If NS desires to tear down a pair pseudo wire, NS sends a Label Withdraw messsage to NAC. On receiving a Label Withdraw message, NAC searches for a LSP for Generalized FEC ID Element TLV SAII and TAII of which are the reverse of those in Generalized FEC ID Element TLV received from NS. If a LSP is found, NAC sends a Label Withdraw mesasge for the FEC and tears down the LSP. MATSUDA Expires August 2004 [Page 5] Internet-Draft Signaling for Access Service Network February 2004 4. Protocol Message Format 4.1 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 pseudo wire 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"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. 4.2 LDP related message format 4.2.1 Generalized ID FEC Element format for Ethernet Access Service 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 describer the format of SAII and TAII in the following. MATSUDA Expires August 2004 [Page 6] Internet-Draft Signaling for Access Service Network February 2004 - value field of SAII for Generalized ID FEC Element in Label Mapping 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"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 plus PPPoE session ID for PPPoE session case, interface index to which Subscriber CE is connected for 801.1X 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 idetifer 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 idetifer is the form of user_id@isp_domain_name, isp_domain_name string can be used as "ISP/VPN identifier". MATSUDA Expires August 2004 [Page 7] Internet-Draft Signaling for Access Service Network February 2004 4.2.2 Generalized ID FEC Element format for IP Access Service - value field of SAII for Generalized ID FEC Element in Label Mapping 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type | Prefix Length | Address Len | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID between Subscriber CE and NAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *"Address Type" indicates whether the IP address assigned to a Subscriber CE is IPv4 or IPv6. The value 4 means IPv4 and the value 6 means IPv6. *"Prefix Length" indicates the prefix length of the IP address assigned to a Subscriber CE. *"Address Len" indicates the length of "IP Address" field in octets. This field should be 4 for IPv4 address and 16 for IPv6 address. *"IP Address" indicates the IP address assigned to a Subscriber CE. *"Connection ID between Subscriber CE and NAC" is an identifier which contains enough information for NAC to identify Subscriber CE (e.g. interface index plus PPPoE session ID for PPPoE session case, interface index to which Subscriber CE is connected for 801.1X 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 The format is the same as that describer in 4.2.2. 4.2.3 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 pseudo wire between Subscriber CE and ISP/VPN CE. MATSUDA Expires August 2004 [Page 8] Internet-Draft Signaling for Access Service Network February 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. 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. MATSUDA Expires August 2004 [Page 9] Internet-Draft Signaling for Access Service Network February 2004 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette and B. Thomas, "LDP Specification", 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 2569 FAX: +81 EMail: tmatsuda@isl.melco.co.jp MATSUDA Expires August 2004 [Page 10]