Internet DRAFT - draft-li-l1vpn-ds-info-distribution

draft-li-l1vpn-ds-info-distribution



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]