L1VPN Working Group K. Jiang Internet-Draft Y. Peng Intended status: Standards Track D. Wang Expires: October 23, 2010 UESTC April 21, 2010 Layer1 vpn dynamic PIT configuration draft-jiang-l1vpn-dynamic-pit-configuration-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes a mechanism of dynamic Port Information Table (PIT) configuration for Layer-1 VPNs (L1VPN). This mechanism allows the customer to configure PIT dynamically via CE-PE signaling. Jiang, et al. Expires October 23, 2010 [Page 1] Internet-Draft L1vpn dynamic PIT configuration April 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Premise . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. PIT configuring architecture . . . . . . . . . . . . . . . . . 3 4.1. Public Control Channel . . . . . . . . . . . . . . . . . . 4 4.2. User network interface address bounding . . . . . . . . . 5 4.3. Customer-Access-Control Architecture . . . . . . . . . . . 5 5. PIT configuration scenarios . . . . . . . . . . . . . . . . . 5 5.1. Initiate a VPN . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Join in an existing VPN . . . . . . . . . . . . . . . . . 7 5.3. Quit from certain VPN . . . . . . . . . . . . . . . . . . 11 5.4. Delete a VPN . . . . . . . . . . . . . . . . . . . . . . . 11 6. User Network Interface (UNI) signaling . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Jiang, et al. Expires October 23, 2010 [Page 2] Internet-Draft L1vpn dynamic PIT configuration April 2010 1. Introduction The purpose of this document is to define a dynamic PIT configuration mechanism for L1VPNs allowing the customer to configure PIT dynamically. The PIT contains a list of tuples for all the ports within its L1VPN as outlined in [RFC5251], and controls the access of each new customer. However, the PIT cannot be configured via CE-PE signaling directly on account of security [RFC5251]. To provide the new customer with more flexibility, this document proposes a mechanism enabling new customers to configure PIT dynamically via Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions (GMPLS RSVP-TE) Signaling [RFC3473]. 2. Terminology 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 [RFC2119]. 3. Premise This document divides the procedure of VPN construction into two phases: 1. VPN information configuration. It includes assignment of VPN-ID, PIT configuration, etc, which are configured before establishing actual LSP between VPN members. 2. Establishing actual LSP. Each VPN member port can establish actual LSP to another VPN ports arbitrarily after Phase 1. All the content of this document belongs to the first phase. 4. PIT configuring architecture To make PIT configuration dynamically by a new customer, a customer- access-control architecture and an additional control channel between CE and PE named Public Control Channel (PCC) are REQUIRED in this document. The public control channel is a special channel dedicated to transporting PIT configuration relevant message. The customer- access-control architecture aims to enable existing L1VPN members to control the access of each new customer. Jiang, et al. Expires October 23, 2010 [Page 3] Internet-Draft L1vpn dynamic PIT configuration April 2010 4.1. Public Control Channel In the context of L1VPN, a CE is connected to a PE via one or more ports consisting of one or more channels or sub-channels. The PCC MAY be supplied by these sub-channels or by any IP channel which is supported by dedicated line or lay2 VPN, lay3 VPN etc. Once a Customer Edge (CE) is connected to service provider network, a PCC SHOULD be bound and configured by service provider. To initiate a new VPN or join in an existing VPN, the new customers SHOULD submit the corresponding requests to its adjacent PE via this PCC. We refer to the CE's address of the PCC as CE Public Control Channel Address (Public-CE-CC-Addr), and the PE's address as the PE Public Control Channel Address (Public-CE-CC-Addr) as shown in figure.1. Public-CE-CC-Addr and Public-CE-CC-Addr are both REQUIRED to be unique to the involved CE-PE pair. +.........................................+ +-----.--+ Control plane +--.-----+ | . | | . | | . |Public-CE-CC-Addr Pulic-PE-CC-Addr| . | | . |-----------------------------------| . | | . |CE-CC-Addr PE-CC-Addr | . | | . |-----------------------------------| . | | +..|...................................|..+ | | CE | | PE | | +..|...................................|..+ | | . | Data plane | . | | . | CPI PPI | . | | . |-----------------------------------| . | | . | VPN-PPI | . | | +..|...................................|..+ | +--------+ +--------+ Figure 1.Address of user network interface And the CPI, PPI and VPN-PPI are Customer Port Identifier, Provider Port Identifier and VPN Provider Port Identifier respectively which are defined in [RFC5251]. The assignment of the PPIs is controlled solely by the service provider, while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN. The CPI, PPI, and VPN-PPI WILL be consulted between CE and PE sequentially for PIT configuration. Jiang, et al. Expires October 23, 2010 [Page 4] Internet-Draft L1vpn dynamic PIT configuration April 2010 4.2. User network interface address bounding When network needs PIT configuration, the user network interface addresses WILL be consulted between CE and PE sequentially. The VPN control channel (CE-CC-Addr and PE-CC-Addr) WILL be determined through public control channel, And the data plane channel (CPI,PPI and VPN-PPI) WILL be bound through its VPN control channel. Once these addresses are fixed, the PIT configuration is finished. 4.3. Customer-Access-Control Architecture This architecture is to release the service provider from traditional complicated VPN access control for each new customer and SHOULD be deployed in customer network without service provider involved. Each PE not only maintains PIT information for all L1VPN associated with it, but also maintains the access control information for all L1VPN. The access information SHOULD contain four items at least as follows: 1. VPN-ID. It is a virtual VPN identifier assigned by service provider when a customer initiates a VPN. It is to allow any new customer to join in it so long as this customer gets the permission of the customer-access-control. And the VPN-ID is REQUIRED to be unique in service provider network. 2. Access-tactic. It is an item to identify the tactic of the customer-access-control for certain VPN. The service provider network needs not recognize it. 3. Access point. It is to indicate the access point address of customer-access-control. 4. PPI of source PE. By means of it, other PEs can locate the source PE for certain VPN-ID conveniently. (We refer to the VPN initiator CE as source CE, and its adjacent PE as source PE.) We refer to the table storing the above information on each PE as VPN-Access-Table. 5. PIT configuration scenarios There are four scenarios needing PIT configuration: 1. Initiate a VPN; 2. Join in an existing VPN; 3. Quit from certain VPN; 4. Delete a VPN; All these scenarios are on the assumption that all the customers have Jiang, et al. Expires October 23, 2010 [Page 5] Internet-Draft L1vpn dynamic PIT configuration April 2010 got the permission from management control system of service provider network. 5.1. Initiate a VPN To initiate a VPN, a customer SHOULD deploy a customer-access-control for its own VPN firstly, and then send an initiate-VPN-request to its adjacent PE from PCC. The content of the request SHOULD contain the bandwidth, tactic of customer-access-control, and access point as shown in Figure 2. +------------------------------------------------+ | bandwidth (1 octets) | +------------------------------------------------+ | tactic of customer-access-control(1 octets) | +------------------------------------------------+ | access point (4 octets) | +------------------------------------------------+ | reserved (4 octets) | +------------------------------------------------+ Figure 2.The initiate-VPN information When the service provider receives this request, it WILL check whether there is enough data plane resource to support the bandwidth requirement. If there is enough resource, the service provider WILL assign a VPN-ID for this customer, and send a VPN-ID-announcement to the customer from PCC as illustrated in Figure 3. Meanwhile, the PIT configuration SHOULD be finished for this customer. Besides, a VPN- access-configuration message WILL be advertised to all PEs through multi-protocol Extensions to BGP [RFC4760]. +------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------+ | reserved (8 octets) | +------------------------------------------------+ Figure 3.The VPN-ID announcement information [RFC4760] defines the format of two BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI, which can be used to announce and withdraw the announcement of reachability information. We introduce a new subsequent address family identifier, named PIT-Dynamic- Jiang, et al. Expires October 23, 2010 [Page 6] Internet-Draft L1vpn dynamic PIT configuration April 2010 configuration-Information (to be assigned by the IANA), and also multiple Network-Layer-Reachability-Informations (NLRIs) formats for carrying the PIT relevant message which are distinguished by sub- type. And a sub-NLRI format is defined for VPN-access-configuration message as shown in Figure 4. And its sub-type SHOULD be set to 1. The VPN-ID, access-tactic, access point, PPI of source PE SHOULD be carried in it. +------------------------------------------------+ | sub-type (1 octet) | +------------------------------------------------+ | Length (1 octet) | +------------------------------------------------+ | VPN-ID Length (1 octet) | +------------------------------------------------+ | VPN-ID (variable) | +------------------------------------------------+ | PPI (length) | +------------------------------------------------+ | PPI of source PE (variable) | +------------------------------------------------+ | Access-tactic (1 octets) | +------------------------------------------------+ | Access-point (4 octets) | +------------------------------------------------+ Figure 4.Encoding of the VPN-access-configuration Note that if the value of the Length of the Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next Hop contains an IPv4 address. If this value is 16, then the Next Hop contains an IPv6 address. Each PE maintains a VPN-Access-Table to keep access-control information for all L1VPN. 5.2. Join in an existing VPN To join in an existing VPN, the new customer (called join-customer) SHOULD send a join-in-request to its adjacent PE (called join-PE) from PCC. The content of the request at least SHOULD contain the VPN-ID associated with the existing VPN as shown in Figure 5. Jiang, et al. Expires October 23, 2010 [Page 7] Internet-Draft L1vpn dynamic PIT configuration April 2010 +------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------+ | reserved (8 octets) | +------------------------------------------------+ Figure 5.The join-in request information When service provider network receives this request, it extracts the VPN-ID information and search local VPN-Access-Table to find out the tactic of the customer-access-control associated with this VPN, and then response to the customer as tactic-announcement shown in Figure 6. +------------------------------------------------+ | Access-tactic (1 octets) | +------------------------------------------------+ | reserved (8 octets) | +------------------------------------------------+ Figure 6.The tactic-announcement information The customer WILL re-encapsulate a re-access-control-request according to the special format corresponding to the access-control tactic, and re-sends to its adjacent PE. The format of this request is shown in Figure 7. The apply-reply status SHOULD set to 1 as an access control request, and set to 0 as an access control reply. The access status is valid only when this message is an access control reply. Note that the identity authentication info WILL be transparently passed by service provider network, and be used by customer-access- control. Therefore, its content is changed according to the tactic of the customer-access-control. +------------------------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------------------------+ | apply-reply status(1bits) | access status(1bit)| reserved(6bits) | +------------------------------------------------------------------+ | Identity authentication info(50 octets) | +------------------------------------------------------------------+ Jiang, et al. Expires October 23, 2010 [Page 8] Internet-Draft L1vpn dynamic PIT configuration April 2010 Figure 7.The re-access-control-request information When the ingress node (join-PE) receives the re-access-control- request, it WILL map the re-access-control-request information into a new sub-NLRI of PIT-Dynamic-configuration-Informationn, called access-request as shown in Figure 8, and its sub-type SHOULD be set to 2. And then send the access-request to the egress node (source PE) through multi-protocol Extensions to BGP [RFC4760]. +----------------------------------------------------+ | sub-type (1 octet) | +----------------------------------------------------+ | re-access-control request information (59 octets) | +----------------------------------------------------+ Figure 8.Encoding of the access-request When the egress node (source PE) receives this access-request, it WILL search local VPN-Access-Table to find out the access point of the customer-access-control associated with this VPN. And the re- access-control request information of the access-request WILL be extracted and mapped into remote-access-request whose format is identical to the re-access-control request shown in figure 7. and then the remote-access-request WILL be sent to the access point from VPN control channel. When the customer-access-control finishes the identity authentication for the new customer, it WILL initiate an access-control-reply message as shown in figure 9, and reply to the source PE. The apply-reply status SHOULD be set to 0 as an access-control-reply. And if the customer-access-control approves this new customer, the access status value SHOULD be set to 1; otherwise, set to 0; +------------------------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------------------------+ | apply-reply status(1bits) | access status(1bit)| reserved(6bits) | +------------------------------------------------------------------+ | Identity authentication info(50 octets) | +------------------------------------------------------------------+ Figure 9.The access-control-reply information Jiang, et al. Expires October 23, 2010 [Page 9] Internet-Draft L1vpn dynamic PIT configuration April 2010 When the egress node (source PE) receives this message, it WILL re- map the access-control-reply information into another new sub-NLRI of PIT-Dynamic-configuration-Information, called access-reply as shown in Figure 10, and its sub-type SHOULD be set to 3. And the access- reply WILL be sent to the join-PE. +----------------------------------------------------+ | sub-type (1 octet) | +----------------------------------------------------+ | access-control reply information (59 octets) | +----------------------------------------------------+ Figure 10.Encoding of the access-reply When the join-PE receives this reply, it checks the access status item. If it is a positive reply, the PE WILL configure PIT for this customer, and send a VPN-port-member-announcement to this customer so that a port topology can be available to it. Then the customer can create/delete physical link towards certain VPN member within the view of the VPN port topology dynamically. The format of this announcement is shown in Figure 11. Meanwhile, the PIT information WILL be advertised to the associated PEs through auto-discovery mechanism [RFC5195]. +------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------+ | CPI num (1 octets) | +------------------------------------------------+ | CPI AFI (2 octets) | +------------------------------------------------+ | CPIs | +------------------------------------------------+ Figure 11.The VPN-port-member-announcement information CPI num: Indicating the number of CPI members. CPI AFI: Indicating the address family identifier of the CPIs. Jiang, et al. Expires October 23, 2010 [Page 10] Internet-Draft L1vpn dynamic PIT configuration April 2010 5.3. Quit from certain VPN To quit from certain VPN, the customer SHOULD send a quit-from-VPN- request to its adjacent PE from VPN control channel as shown in Figure 12. +------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------+ | reserved (8 octets) | +------------------------------------------------+ Figure 12.The quit-from-VPN request information The service provider WILL check whether there are VPN physical links associated with this customer still. If the physical link exists, it SHOULD be removed compulsively firstly (it is out of scope of this document). Then the corresponding PIT configuration WILL be deleted and a quit-from-VPN-reply WILL be send to the customer from public control channel. Meanwhile, the auto-discovery mechanism [RFC5195] WILL be triggered. The format of quit-from-VPN-reply is shown in figure 13. If the reply is an ack, the status item SHOULD be set to 1; otherwise, set to 0. +------------------------------------------------+ | L1vpn VPN-ID (8 octets) | +------------------------------------------------+ | status(2bits) | reserved (6 bits) | +------------------------------------------------+ Figure 13.The quit-from-VPN-reply information 5.4. Delete a VPN To delete a VPN that initiated by himself, the customer SHOULD send a delete-VPN request to its adjacent PE from VPN control channel, the parameter of the request is same to the quit-from-VPN request. When the PE receives this request, it WILL check whether there are VPN members or physical links associated with this very VPN still. If the physical link exists, it SHOULD be removed compulsively and the members WILL be forced to quit from this VPN firstly. Then the corresponding PIT configuration WILL be deleted and a delete-VPN- reply WILL be send to the customer from public control channel. Meanwhile, auto-discovery mechanism [RFC5195] WILL be triggered. The Jiang, et al. Expires October 23, 2010 [Page 11] Internet-Draft L1vpn dynamic PIT configuration April 2010 format of delete-VPN-reply is identical to the quit-from-VPN-reply as shown in figure13. 6. User Network Interface (UNI) signaling For the transmission of the PIT relevant message between CE and PE, we introduce a new object class (to be assigned by the IANA) to GMPLS RSVP-TE extensions [RFC3473], namely PIT-Dynamic-Configuration objcet. It MAY be carried in Path message or Resv message. This new object contains multiple C-Types (to be assigned by the IANA). And each message described in the above sections WILL be mapped into unique C-Types of the PIT-Dynamic-Configuration object. These massages include initiate-VPN-request, VPN-ID-announcement, join-in- request, tactic-announcement, re-access-control-request, remote- access-request, access-control-reply, VPN-port-member-announcement, quit-from-VPN request, quit-from-VPN-reply and delete-VPN-reply. All signaling procedures are identical to the GMPLS extensions specified in [RFC3473], except as noted in this document. And the signaling procedure about the new object is as described in the above sections. 7. IANA Considerations This document requires assignment of a new SAFI, called PIT-Dynamic- configuration-Information (see Section 4). This assignment has to be done from the Subsequent Address Family Identifier (SAFI) registry using the Standards Action allocation procedures. And the Class-num and C-Type of PIT-Dynamic-Configuration object (see Section 5) require to be assigned. 8. Security Considerations Since the PIT can be configured by the customer via signaling between CE and PE, the L1VPN members SHOULD responsible for access control for each new customer. Thus, much security consideration is transfered to the mechanism of the customer-access-control. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching Jiang, et al. Expires October 23, 2010 [Page 12] Internet-Draft L1vpn dynamic PIT configuration April 2010 (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008. [RFC5251] Fedyk, D., Rekhter, Y., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008. Authors' Addresses KunJun Jiang University of Electronic Science and Technology of China 2006 Xiyuan Road Gaoxinxiqu Chengdu 200240 CN Phone: +86 13540321287 Email: jiangkunjun2003@163.com Yunfeng Peng University of Electronic Science and Technology of China 2006 Xiyuan Road Gaoxinxiqu Chengdu, 200240 CN Email: yfpeng@uestc.edu.cn Jiang, et al. Expires October 23, 2010 [Page 13] Internet-Draft L1vpn dynamic PIT configuration April 2010 Dong Wang University of Electronic Science and Technology of China 2006 Xiyuan Road Gaoxinxiqu Chengdu 200240 CN Email: dongwang@uestc.edu.cn Jiang, et al. Expires October 23, 2010 [Page 14]