Network Working Group Dan Li Jianhua Gao Internet Draft Huawei Proposed Status: Standards Track Expires: December 2006 June, 2006 Directory Server based Information Distribution for L1VPN draft-li-l1vpn-ds-info-distribution-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This document describes a Directory Server based VPN membership information distribution mechanism for layer-1 VPNs. The mechanism enables PEs to discover which other PEs have ports attached to CEs that are members of the same VPN, and allows PEs to discover attributes of currently configured CE-PE links and their associations with layer-1 VPNs. This document builds on the Layer One VPN Framework and provides an auto-discovery mechanism as discussed in Li Expires December 2006 [Page 1] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 the Layer One VPN Basic Mode document. This mechanism may be applied to the layer-1 VPN basic mode. 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 [RFC2119]. Table of Contents 1. Introduction................................................2 2. Procedures..................................................3 2.1. Adding new CE to the VPN................................4 2.2. Deleting a CE from the VPN..............................5 2.3. Updating L1VPN information in Directory Server...........5 3. Security Considerations......................................6 4. IANA Considerations.........................................7 5. Acknowledgments.............................................7 6. References..................................................7 6.1. Normative References....................................7 6.2. Informative References..................................7 7. Author's Addresses..........................................8 8. Full Copyright Statement.....................................8 9. Intellectual Property Statement..............................9 1. Introduction [L1VPN-BM] describes the motivation to discover L1VPN membership and access information. This information may be discovered through configuration, by using routing protocols, or through other means. [L1VPN-BGP] describes a BGP-based L1VPN auto-discovery mechanism, and [L1VPN-IGP] describes an OSPF-based L1VPN auto-discovery mechanism, both mechanisms rely on routing protocols, and some extensions to these protocols are required in order to support L1VPN auto-discovery. Manual configuration is another option. When we want to add or delete a VPN membership, the PE can be manually configured with the updated VPN membership information. In case of a large number of PEs in the network, it turns out to be a serious manageability issue, because each time a VPN membership is added or deleted, all the related PEs need to be informed. This document describes another way for the VPN membership information to be exchanged between PEs. This method uses Directory Li Expires December 2006 [Page 2] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 Server based information distribution for the L1VPN. The Directory Server is maintained by the service provider, and the L1VPN information with respect to the CE-PE association and currently configured CE-PE link attributes is stored in the Directory Server. The information that needs to be discovered on a PE local port is the remote CPI and the VPN-PPI. In many cases if LMP is used between the CE and PE, LMP can exchange this information. The L1VPN information is registered to the Directory Server by the PE which discovers or is informed of the CE-PE relationship. On receiving a service request from a CE, the associated PE can look up the corresponding L1VPN information from the Directory Server. This mechanism is applicable to the L1VPN basic mode. 2. Procedures Figure 1 shows the Directory Server based auto-discovery for L1VPN. All the CE-PE associations and CE-PE link attribute information is maintained by the Directory Server. By sending requests to the Directory Server, the PE knows which PEs belong to the same VPN, and how to compute a path from one CE to a remote CE - that is, the PE can find out which remote PE gives access to the remote CE. Li Expires December 2006 [Page 3] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 +-----------+ | Directory | +----+ Server +----+ | | PIT | | | +-----------+ | |<--- Register & --->| | Distribution | PE | | PE +-----+---+ +---+-----+ +-----+ |+-------+| |+-------+| +-----+ |VPN-A| || VPN-A || || VPN-A || |VPN-A| | CE1 |--|| PIT || || PIT ||--| CE2 | +-----+ |+-------+| |+-------+| +-----+ | | | | +-----+ |+-------+| |+-------+| +-----+ |VPN-B| || VPN-B || -------- || VPN-B || |VPN-B| | CE1 |--|| PIT ||-( GMPLS )-|| PIT ||--| CE2 | +-----+ |+-------+| (Backbone ) |+-------+| +-----+ | | --------- | | +-----+ |+-------+| |+-------+| +-----+ |VPN-C| || VPN-C || || VPN-C || |VPN-C| | CE1 |--|| PIT || || PIT ||--| CE2 | +-----+ |+-------+| |+-------+| +-----+ +---------+ +---------+ Figure 1 Directory Server based auto-discovery for L1VPN 2.1. Adding new CE to the VPN When a new CE needs to be added to the VPN, the CE sends the request to the attached PE with the customer port identifier (CPI) and which VPN ID it belongs to, and the PE sends the authentication request to the Directory Server. If the CPI and VPN ID are confirmed by the Directory Server based on the policy, the Provider Port Identifier (PPI) is assigned. The CE-PE link attributes can also be discovered by LMP or by other mechanism. The PE SHOULD register the CE-PE association and the CE-PE link attribute information with the Directory Server, and this information MAY also need to be distributed by the Directory Server to other PEs which belong to same VPN. If the CPI and VPN ID are rejected by the Directory Server based on the policy, then the CE SHOULD not be added to the VPN. Li Expires December 2006 [Page 4] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 2.2. Deleting a CE from the VPN When PE receives a deletion request from the associated CE, the PE sends the request to the Directory Server. The Directory Server SHOULD check the authentication based on the policy. If the request is confirmed, then the corresponding L1VPN information related to this CE will be deleted, and a confirmation message sent to the PE to inform it that the request has completed. Meanwhile, the Directory Server MAY also send an update messages to all PEs of the same VPN to update the L1VPN information to reflect the deletion of the CE. If the request is rejected, an error message will be returned to the CE through the PE. 2.3. Updating L1VPN information in the Directory The L1VPN information stored in the Directory MAY be manually updated by the service provider. In this case, all the PEs SHOULD be informed by Directory Server with the updated L1VPN information. The L1VPN information stored in each PE SHOULD be synchronized with that stored in the Directory Server. 2.4. Pull or Push model The Directory MAY be implemented as a centralized directory, in which case each PE SHOULD look up the VPN membership information for each request from the associated CE by sending a query request to the Directory Server. This is called the Pull model. The Directory Server MAY distribute the VPN membership information to the PEs which belong to the same VPN. In this way, the PE only need to look up the VPN membership information from its local database for each request from the associated CE. The Directory is distributed, and this is called the Push model. 3. Application to Inter-AS L1VPN This mechanism also can be applied to the inter-AS network scenario, where one Directory Server MAY be used for the entire network, or each AS has its own Directory Server. 3.1. Single Directory Server When there is only one Directory Server that supports the entire network, the Directory Server doesn't belong to any AS network. The Li Expires December 2006 [Page 5] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 same procedure as for a single AS network (described in Section 2) is applied to this scenario. 3.2. Multiple Directory Server In the case where each AS has its own Directory Server, then the interactions between these Directory Servers needs to be considered. The additional procedures for the coordination between these Directory Servers is out of scope of this document, and for further study. Such procedures are likely to be heavily dependent on inter-AS policy. 4. Security Considerations The solution presented in this document describes how PEs dynamically register and learn L1VPN specific information from the Directory Server. The Directory Server is maintained by the service provider, and the information stored in the Directory is about CE-PE associations and the attributes of CE-PE links. This is information specific to the service provider. It is the intention of this model that only PEs need access to the Directory, and other access SHOULD be restricted. Directory access protocols (such as LDAP [RFC4513]) are designed to provide full security against false entry into databases (through authentication), false distribution of data (through authentication and verification), and illicit access to information (through authentication and encryption). A Directory Server implementation in support of L1VPN discovery MUST use an established Directory access protocol that includes full security features. Consideration MUST also be given to Denial of Service attacks where false information requests are sent to the Directory Server or to PEs holding the distributed Directory. Again, Directory access protocols (such as LDAP [RFC4513]) contain such provisions, but it may also be necessary for PEs and the Directory Server to perform additional function such as request throttling to ensure good performance in the face of a Denial of Service attack. Li Expires December 2006 [Page 6] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 5. IANA Considerations This document defines no new protocols or extensions and makes no requests to IANA for registry management. 6. Acknowledgments We would like to thank Adrian Farrel for his useful comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic Mode", draft-fedyk-l1vpn-basic-mode (work in progress). 7.2. Informative References [L1VPN-FRMWK] Tomonori Takeda, et al., " Framework and Requirements for Layer 1 Virtual Private Networks", draft-ietf-l1vpn- framework (work in progress). [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto-Discovery for L1VPNs ", draft-ietf-l1vpn-bgp-auto- discovery (work in progress). [L1VPN-IGP] Igor B., Lou B., "OSPF-based L1VPN Auto-Discovery", draft-bryskin-l1vpn-ospf-auto-discovery (work in progress). [RFC4513] R. Harrison, "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. Li Expires December 2006 [Page 7] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 8. Author's Addresses Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972910 Email: danli@huawei.com Yongliang Xu Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972908 Email: ylxu@huawei.com Jianhua Gao Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972902 Email: gjhhit@huawei.com 9. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Li Expires December 2006 [Page 8] Internet-Draft draft-li-l1vpn-ds-info-distribution-00.txt June 2006 10. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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". Li Expires December 2006 [Page 9]