Skip to main content

Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Enhanced Mode
draft-belotti-app-statement-l1vpn-em-00

The information below is for an old version of the document.
Document Type Active Internet-Draft (individual)
Authors Sergio Belotti , Don Fedyk , Papadimitriou Dimitri
Last updated 2012-07-09
Stream (None)
Formats plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-belotti-app-statement-l1vpn-em-00
Network Working Group                                    Sergio Belotti 
Internet Draft                                                Don Fedyk 
Intended status: Informational                    Dimitri Papadimitriou 
                                                         Alcatel-Lucent 
                                                                         
 
                                    
Expires: January 2013                                      July 9, 2012 
                                    
 
    Applicability Statement for Layer 1 Virtual Private Network (L1VPN) 
                               Enhanced Mode 
                draft-belotti-app-statement-l1vpn-em-00.txt 

Abstract 

   This document provides an applicability statement on the use of 
   Generalized Multiprotocol Label Switching (GMPLS) protocols and 
   mechanisms to satisfy the requirements of the Layer 1 Virtual 
   Private Network (L1VPN) Enhanced Mode.  

   L1VPNs provide customer services and connectivity at layer 1 over 
   layer 1 networks. The operation of L1VPNs is divided into the Basic 
   Mode and the Enhanced Mode, where the Enhanced Mode of operation may 
   also include exchange of routing information between the layer 1 
   network and the customer domain. 

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), 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 

   This Internet-Draft will expire on January 9, 2009. 


 
Belotti et al.         Expires January 9, 2013                 [Page 1] 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

Copyright Notice 

   Copyright (c) 2012 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. 

    

 
 
Belotti et al.         Expires January 9, 2013                 [Page 2] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

Table of Contents 

   1. Introduction...................................................3 
   2. Conventions Used in This Document..............................4 
      2.1. Terminology...............................................4 
   3. Existing Solutions.............................................4 
   4. General Guidelines.............................................4 
   5. Overlay Extension Service Model................................6 
      5.1. Overview of the Service Model.............................6 
      5.2. Applicability of Existing Solutions.......................6 
      5.3. Incremental protocol extensions...........................7 
   6. Virtual Node Service Model.....................................7 
      6.1. Overview of the Service Model.............................7 
      6.2. Applicability of Existing Solutions.......................7 
   7. Virtual Link Service Model.....................................8 
      7.1. Overview of the Service Model.............................8 
      7.2. Applicability of Existing Solutions.......................8 
   8. Per-VPN Peer Service Model.....................................8 
      8.1. Overview of the Service Model.............................8 
      8.2. Applicability of Existing Solutions.......................9 
   9. Manageability Considerations...................................9 
   10. Security Considerations.......................................9 
   11. References....................................................9 
      11.1. Normative References.....................................9 
      11.2. Informative References..................................10 
   12. Acknowledgments..............................................12 
   13. Author's Addresses ..........................................12 
    
1. Introduction 

   This document provides an applicability statement on the use of 
   existing Generalized Multiprotocol Label Switching (GMPLS) protocols 
   and mechanisms to the Layer 1 Virtual Private Network (L1VPN) 
   Enhanced Mode. 

   In particular, this document shows section by section (from Section 
   5 to 8) the applicability of GMPLS protocols and mechanisms to each 
   sub-model of the Enhanced Mode mentioned in [RFC4847]. 

   Note that discussion in this document is limited to areas where 
   GMPLS protocols and mechanisms are relevant.  

   As will be described in this document, support of the Overlay 
   Extension service model and the Virtual Node service model are well 
   covered by existing protocol mechanisms already described in other 
   documents, with only minor protocol extensions required. The Virtual 
   Link service model and the Per-VPN Peer service model are not 
 
 
Belotti et al.         Expires January 9, 2013                 [Page 3] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

   explicitly covered by existing documents, and would require 
   extension of current GMPLS protocols and mechanisms  

   Solutions should be scalable and manageable per RFC 4847. Solutions 
   should not require L1VPN state to be maintained on the P devices as 
   much as possible.  
      
2. 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 [RFC2119].  

   In this document, these words will appear with that interpretation   
   only when in ALL CAPS. Lower case uses of these words are not to be    
   interpreted as carrying RFC-2119 significance. 

3. Terminology 

   The reader is assumed to be familiar with the terminology in 
   [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026] and 
   [RFC4847], [RFC5251], [RFC5253], [RFC5252] and [RFC4208].  

4. Existing Solutions 

   This section lists existing solution documents that describe how the 
  L1VPN Enhanced Mode may be constructed using the mechanisms of GMPLS. 
  This document draws on those solutions and explains their 
  applicability with respect to the framework described in [RFC4847]. 
  Further solution documents may be listed in a future version of this 
  document.  

  - [RFC5251] addresses L1VPN Basic Mode signaling.  
  - [RFC4208] addresses the application of GMPLS to the Overlay model. 
  - [RFC5252] describes OSPF based autodiscovery mechanisms. 
   

  Note that although [RFC5251] specifies signaling mechanisms for L1VPN 
  Basic Mode, it is applicable to the L1VPN Enhanced Mode, unless 
  otherwise specified.  

5. General Guidelines  

   This section provides general guidelines for L1VPN solutions. Note 
   that applicability to specific sub-models will be separately 

 
 
Belotti et al.         Expires January 9, 2013                 [Page 4] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

   described in following sections. One important general design 
   guideline is that protocol mechanisms should be re-used where 
   possible. This means that solutions should be incremental, building 
   on existing protocol mechanisms rather than developing wholly new 
   protocols. Further, as service models are extended or developed 
   resulting in the requirement for additional functionalities, deltas 
   should be added to the protocol mechanisms rather than developing 
   new techniques. [RFC4847] describes how the service models can be 
   seen to provide "cascaded" functionality, and this should be 
   leveraged to achieve re-use of protocol extensions so that, for 
   example, it is highly desirable that the same signaling protocols 
   and extensions are used in both the Basic Mode and the Enhanced 
   Mode.  

   In addition, the following are general guidelines:    

  - The support of L1VPNs should not necessitate any change to core 
     (P)devices. Therefore, any protocol extensions made to facilitate 
     L1VPNs need to be made in a backward compatible way allowing GMPLS 
     aware P devices to continue to function.  
  - Customer (C) devices not directly involved in providing L1VPN  
  - Services should also be protected from protocol extensions made to 
     support L1VPNs. Again, such protocol extensions need to be 
     backwards compatible. Note however, that some L1VPN service models 
     allow for VPN connectivity between C devices rather than between 
     CE devices: in this case, the C devices may need to be aware of 
     protocol extensions.  
  - Solutions should aim to minimize the protocol extensions on CE 
     devices.  
  - Solutions should be scalable and manageable per RFC 4847. 
     Solutions should not require L1VPN state to be maintained on the P 
     devices as much as possible.  
  - Solutions should be secure. Providers should be able to screen and 
     protect information based on their operational policies per RFC 
     4847.  
  - Solutions should provide an operational view of the L1VPN for the 
     customer and provider. There should be a common operational and 
     management perspective in regard to other (L2 and L3) VPN services 
     per RFC 4847.  
    

 
 
Belotti et al.         Expires January 9, 2013                 [Page 5] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

6. Overlay Extension Service Model 

6.1. Overview of the Service Model 

  This service model complements the Basic Mode and may assume all of 
  the requirements, solutions and work items for that model.  

  In this service model, a CE receives from its attached PEs a list of 
  TE link addresses to which it can request a VPN connection (i.e., 
  membership information). 

  The CE may also receive some TE information concerning these CE-PE 
  links within the VPN (e.g., switching type). 

  Further information may be found in [draft-fedyk-ccamp-l1vpn-extnd-
  overlay]. 

  The CE does not receive any of the following from the PE:  

  - Routing information about the core provider network.  
  - Information about P device addresses.  
  - Information about P-P, PE-P or PE-PE TE links.  
  - Routing information about other customer sites. The CE may have 
     access to routing information about the remainder of the VPN (C-C 
     and CE-C links), but this is exchanged by control plane tunneling 
     on the CE-CE connections and is not passed to the CE in the 
     control plane exchange between PE and CE. 
   
 
6.2. Applicability of Existing Solutions 

   The following are required in this service model (in addition to 
   requirements in the L1VPN Basic Mode:  

  - Interactions between an edge node (CE) and it's adjacent (at the 
     data plane) core-node (PE).  
  - VPN membership information exchange between a CE and PE.  
  - CE-PE TE link information exchange between a CE and a PE.  
   
   RFC 4208 addresses RSVP-TE procedures between an edge-node and a 
   core-node in the overlay model.  RFC5252 enables PE devices using 
   OSPF to dynamically learn about the existence of each other, and 
   attributes of configured CE links and their association with L1VPNs. 

 
 
Belotti et al.         Expires January 9, 2013                 [Page 6] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

   Furthermore, [RFC5252] allows the exchange of CE-PE TE link 
   information between a CE and a PE.  

6.3. Incremental protocol extensions  

  It can be useful for the ingress node to be able to convey TE metrics 
  (e.g., IGP metric, TE metric, hop counts, latency, etc.) that the 
  path computation algorithm (at the remote node performing route 
  computation or expansion) can optimize for. Similarly, it can be 
  useful for the ingress node to be able to indicate a TE metric bound 
  for the loose segment being expanded by the remote node, (e.g., 
  [DRAFT-TE-OBJ-FUNC-METRIC-BOUND]). 
  In a similar manner, as described in [DRAFT-TE-METRIC-RECORD], there 
  are RSVP-TE requirements for the support of the automatic discovery 
  of cost, latency and latency variation attributes of an LSP. These 
  requirements are very similar to the requirement for discovering the 
  Shared Risk Link Groups (SRLGs) associated with the route taken by an 
  LSP (e.g., [DRAFT-SRLG-RECORDING]).  
  It is also possible to improve route diversity for single-homed and 
  dual-homed customer LSPs, which is a common requirement.  This may be 
  achieved via signaling extensions that provide shared constraint 
  information for path diversity.  Specifically, mechanisms that enable 
  communication to the node computing/expanding the LSP signaled, 
  information to exclude the route taken by a particular LSP or the 
  route taken by all LSPs belonging to a single tunnel(e.g., [DRAFT-
  EXTENDED-OVERLAY]).      
  
7. Virtual Node Service Model 

7.1. Overview of the Service Model 

   In this service model, there is a private routing exchange between 
   the CE and the PE, or to be more precise between the CE routing 
   protocol instance and the VPN routing protocol instance running on 
   the PE. The provider network is considered as one private node from 
   the customer's perspective. The routing information exchanged 
   between the CE and the PE includes CE-PE TE link information, 
   customer network (i.e., remote CE sites), and may include TE links 
   (Forwarding Adjacencies) connecting CEs (or Cs) across the provider 
   network as well as control plane topology information from the 
   customer network (i.e., CE sites). 

7.2. Applicability of Existing Solutions 

   The following are required in this service model:  
 
 
Belotti et al.         Expires January 9, 2013                 [Page 7] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

  - VPN routing  
  - CE-CE Label Switching Path (LSP) setup, deletion, and modification 
     signaling. 
      
   It is possible to use IGP-based auto-discovery (based on [RFC5252]). 

   Signaling mechanisms are covered by [RFC5251].  

8. Virtual Link Service Model  

8.1. Overview of the Service Model  

   In this service model, virtual links are established between PEs. A 
   virtual link is assigned to each VPN and disclosed to the 
   corresponding CEs. The routing information exchanged between the CE 
   and the PE includes CE-PE TE links, customer network (i.e., remote 
   CE sites), virtual links (i.e., PE-PE links) assigned to each VPN, 
   and may include CE-CE (or C-C) Forwarding Adjacencies as well as 
   control plane topology from the customer network (i.e., CE sites).  

 
   NOTE - Resource management for a dedicated data plane is a mandatory 
   requirement for the Virtual Link service model. This could be 
   realized by assigning pre-configured FA-LSPs to each VPN routing 
   protocol instance (no protocol extensions needed) in order to  
   instantiate the necessary FAs. 
     
8.2. Applicability of Existing Solutions 

   Currently, there is no solution document for this type of service 
   model.  

9. Per-VPN Peer Service Model  

9.1. Overview of the Service Model  

   In this service model, the provider partitions TE links within the 
   provider network per VPN. The routing information exchanged between 
   the CE and the PE includes CE-PE TE links, customer network (i.e., 
   remote CE sites), as well as partitioned portions of the provider 
   network, and may include CE-CE (or C-C) Forwarding Adjacencies and 
   control plane topology from customer network (i.e., CE sites). Note 
   that PEs may abstract routing information about the provider network 
   and advertise it to CEs.  

 
 
Belotti et al.         Expires January 9, 2013                 [Page 8] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

   Note scalability must be carefully considered for advertising 
   provider network routing information to the CE [RFC4726].  

9.2. Applicability of Existing Solutions  

   Currently, there is no solution document for this type of service 
   model.  

10. Manageability Considerations  

   Section 11 of [RFC4847] describes manageability considerations for 
   L1VPNs. 

   This document defines a following new manageability requirement 
   specific for the L1VPN Enhanced Mode.  

   MIB modules MUST be available for any protocol extensions for the 
   L1VPN Enhanced Mode.  

   A future revision of this document may cover more aspects.  

11. Security Considerations  

   Section 12 of [RFC4847] describes security considerations for 
   L1VPNs. This document defines a following new security requirements 
   specific for the L1VPN Enhanced Mode.  

   In the L1VPN Enhanced Mode, since there is a routing adjacency 
   between a CE and a PE, care must be taken whether the provider 
   network's control plane topology information is leaked to the CE. 
   Due to security concerns, this is not recommended in general, and 
   there must be a mechanism to prevent such operation. A future 
   revision of this document may cover more aspects.  

12. IANA Considerations 

   This document has no actions for IANA. 

13. References  

13.1. Normative References 

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate 
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 

 
 
Belotti et al.         Expires January 9, 2013                 [Page 9] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

   [RFC4208]      Swallow, G., et al., "Generalize Multiprotocol Label 
                  Switching(GMPLS) User-Network Interface: Resource 
                  ReserVation Protocol-Traffic Engineering(RSVP-TE) 
                  Support for the Overlay Model," RFC 4208, October 
                  2005. 

   [RFC4847]      Takeda, T., Editor "Framework and Requirements Layer 
                  1 Virtual Private Networks", RFC 4847,   

   [RFC5251]      Fedyk, D., et al., "Layer 1 VPN Basic Mode", RFC5251, 
                  July 2008. 

   [RFC5252]      Bryskin, I., Berger, L., "OSPF-Based Layer 1 VPN 
                  Auto-Discovery", RFC 5252, July 2008. 

   [RFC5253]      Takeda, T. et al., "Applicability Statement for 
                     Layer 1 Virtual Private Network (L1VPN) Basic 
                  Mode", RFC 5253, July 2008. 

13.2. Informative References 

        

   [Y.1312]        Y.1312 - Layer 1 Virtual Private Network Generic  
                   requirements and architecture elements, ITU-T  
                   Recommendation, September 2003.   

   [Y.1313]        Y.1313 - Layer 1 Virtual Private Network service and 
                   network architectures, ITU-T Recommendation, July 
                   2004.  
    
   [RFC3031]       Rosen, E., Viswanathan, A. and R. Callon,  
                   "Multiprotocol label switching Architecture", RFC  
                   3031, January 2001.  
        
   [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T.,  
                   Srinivasan, V.  and G. Swallow, "RSVP-TE:  
                   Extensions to RSVP for LSP Tunnels", RFC 3209,  
                   December 2001.  
        

    [RFC3471]       Berger, L., Editor, "Generalized Multi-Protocol  
                   Label Switching (GMPLS) Signaling Functional  
                   Description", RFC 3471, January 2003.  
     
    [RFC3473]      Berger, L., Editor "Generalized Multi-Protocol  
                      Label Switching (GMPLS) Signaling - Resource  
 
 
Belotti et al.         Expires January 9, 2013                [Page 10] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

                   ReserVation Protocol-Traffic Engineering (RSVP-TE)  
                   Extensions", RFC 3473, January 2003.  
        

    [RFC4202]      Kompella, K., et al., "Routing Extensions in  
                  Support of Generalized Multi-Protocol Label Switching 
                  (GMPLS)", RFC 4202, October 2005.  
        
    [RFC4026]      Anderssion, L., and Madsen, T., "Provider  
                  Provisioned Virtual Private Network (VPN) 
                  Terminology", RFC 4026, March 2005.  
    
    [RFC4726]      Farrel, A., et al., "A Framework for Inter-Domain 
                  Multiprotocol Label Switching                           
                  Traffic Engineering", RFC 4726, November 2006. 
        
     
   [DRAFT-TE-OBJ-FUNC-METRIC-BOUND]   
                  Ali Z., et al., Resource ReserVation Protocol-                
                  Traffic Engineering (RSVP-TE) extension for signaling 
                  Objective Function and Metric Bound draft-ali-ccamp-
                  rc-objective-function-metric-bound-01, work in 
                  progress  
   
    [DRAFT-SRLG-RECORDING]  
                  F. Zhang, D. Li, O. Gonzalez de Dios, C.  
                  Margaria. C, " RSVP-TE Extensions for Collecting SRLG 
                  Information ", draft-zhang-ccamp-srlg-fa-
                  configuration-05, work in progress.   
   
    [DRAFT-TE-METRIC-RECORD]  
                  ALI Z.,et al., "Resource ReserVation Protocol- 
                  Traffic Engineering (RSVP-TE) extension for recording 
                  TE Metric of a Label Switched Path", draft-ali-ccamp-
                  te-metric-recording-01.txt, work in progress  
      
   
    [DRAFT-EXTENDED-OVERLAY] 
                  Fedyk D., et al., "Layer 1 VPN Enhanced Mode -    
                  Overlay Extension Service Model", draft-fedyk-ccamp-
                  l1vpn-extnd-overlay-00, work in progress  
   
   

 
 
Belotti et al.         Expires January 9, 2013                [Page 11] 
 
 

Internet-DraftApplicability of L1VPN Enhanced ModeBelotti et  July 2012 
    

14. Acknowledgments 

   The authors would like to thank the editor and authors of draft-
   ietf-l1vpn-applicability-enhanced-mode (Tomonori Takeda, Hamid Ould-
   Brahim, Adrian Farrel, Deborah Brungard, Dimitri Papadimitriou) and 
   the members of the L1VPN working group for their contribution, in 
   recognition that most of the text in this draft derives from their 
   effort.  

   The authors would also like to thank Dieter Beller, Lieven Levrau, 
   and Eve Varma for their contributions to this work. 

           

15. Author's Addresses  

      Sergio Belotti (Alcatel-Lucent) 
      VIA TRENTO 30 
      20059 Vimercate 
      Italy 
      Phone: +39 039 686 3033 
      sergio.belotti@alcatel-lucent.com 
    

      Don Fedyk (Alcatel-Lucent) 
      Groton,MA 01450 
      United States 
      Phone: +1 978 467 5645 
      Email: Donald.Fedyk@alcatel-lucent.com 
       

      Dimitri Papadimitriou (Alcatel-Lucent) 
      Copernicuslaan 50 
      2018 Antwerp 
      Belgium 
      Phone: +32 3 2408491   
      Email: dimitri.papadimitriou@alcatel-lucent.com   
    

 
 
Belotti et al.         Expires January 9, 2013                [Page 12]