Skip to main content

Mutually Exclusive Link Group (MELG)
draft-beeram-ccamp-melg-00

The information below is for an old version of the document.
Document Type This is an older version of an Internet-Draft whose latest revision is Expired
Authors Vishnu Pavan Beeram , Igor Bryskin
Last updated 2013-02-17
Stream (None)
Formats
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-beeram-ccamp-melg-00
CCAMP Working Group                            Vishnu Pavan Beeram (Ed) 
Internet Draft                                         Juniper Networks 
Intended status: Standards Track                      Igor Bryskin (Ed) 
                                                ADVA Optical Networking 
      
Expires: August 18, 2013                              February 18, 2013 
                                         
      
                                           
                   Mutually Exclusive Link Group (MELG) 
                      draft-beeram-ccamp-melg-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), 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 August 18, 2013. 

Copyright Notice 

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

      
      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 1]

Internet-Draft                   MELG                     February 2013 
         

   Section 4.e of the Trust Legal Provisions and are provided without 
   warranty as described in the Simplified BSD License. 
          
Abstract 

   This document introduces the concept of MELG ("Mutually Exclusive 
   Link Group") and discusses its usage in the context of mutually 
   exclusive Virtual TE Links. 

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]. 
         

Table of Contents 

         
   1. Introduction...................................................2 
   2. Mutually Exclusive Virtual TE Links............................3 
   3. Mutually Exclusive Link Group..................................5 
   4. Protocol Extensions............................................6 
      4.1. OSPF......................................................6 
      4.2. ISIS......................................................7 
   5. Security Considerations........................................8 
   6. IANA Considerations............................................8 
      6.1. OSPF......................................................8 
      6.2. ISIS......................................................8 
   7. Normative References...........................................8 
   8. Acknowledgments................................................9 
         
1. Introduction 

   A Virtual TE Link (as defined in [RFC6001]) advertised into a Client 
   Network Domain represents a potentiality to setup an LSP in the 
   Server Network Domain to support the advertised TE link. The Virtual 
   TE Link gets advertised like any other TE link and follows exactly 
   the same rules that are defined for the advertising, processing and 
   use of regular TE links [RFC4202]. However, "mutual exclusivity" is 
   one attribute that is specific to Virtual TE links. This document 
   discusses the need to advertise this information and the means to do 
   so. 

        
Beeram, et al          Expires August 18, 2013                 [Page 2] 

Internet-Draft                   MELG                     February 2013 
         

2. Mutually Exclusive Virtual TE Links 

   Consider the network topology depicted in Figure 1a. This is a 
   typical packet optical transport deployment scenario where the WDM 
   layer network domain serves as a Server Network Domain providing 
   transport connectivity to the packet layer network Domain (Client 
   Network Domain).   

                              | 
                              | +---+            /-\ 
                              | |   | Router    (   ) WDM  
                              | +---+ Node       \-/  node 
                              |________________________________ 
                                      
 +---+        /-\          /-\           /-\          +---+ 
 | B |-------( E )--------( G )---------( J )---------| C | 
 +---+        \-/          \-/           \-/          +---+ 
                          /   \         /   \ 
                         /     \       /     \ 
                        /       \     /       \ 
                       /         \   /         \ 
                      /           \ /           \ 
     +---+          /-\           /-\           /-\          +---+ 
     | A |---------( F )---------( H )---------( I )---------| D | 
     +---+          \-/           \-/           \-/          +---+ 

                    Figure 1a: Sample topology  

     -------------                        |  [ ] Client TE Node 
     | Client TE |                        |  +++ Client TE Link 
     | DataBase  |                        |_____________________                 
     ------------- 
        [B] ++++++++ [E]                  [J] +++++++++ [C] 
                       
                                       
                             
        [A] ++++++++ [F]                  [I] +++++++++ [D]  
              

                     Figure 1b: Client TE Database 

      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 3]

Internet-Draft                   MELG                     February 2013 
         

   Nodes A, B, C and D are IP routers that are connected to an Optical 
   WDM transport network. E, F, G, H, I and J are WDM nodes that 
   constitute the Server Network Domain. The border nodes (E, F, I and 
   J) operate in both the server and client domains. Figure 1b depicts 
   how the Client Network Domain TE topology looks like when there are 
   no Client TE Links provisioned across the optical domain. 

                              | *****  F-J WDM Path (lambda 192000)              
                              | @@@@@  E-I WDM Path (lambda 192000) 
                              |________________________________ 
                                     
 +---+        /-\ @@@@@@@@ /-\           /-\          +---+ 
 | B |-------( E )--------( G )---------( J )---------| C | 
 +---+        \-/         *\-/*@       @*\-/@         +---+ 
                         */   \*@     @*/   \@ 
                        */     \*@   @*/     \@ 
                       */       \*@ @*/       \@ 
                      */         \*@*/         \@ 
                     */           \*/           \@ 
     +---+          /-\           /-\           /-\          +---+ 
     | A |---------( F )---------( H )---------( I )---------| D | 
     +---+          \-/           \-/           \-/          +---+ 

           Figure 2a: Mutually Exclusive potential WDM paths 

      ------------   |  TE-Links E-I and F-J are mutually exclusive   
      | Client-TE|   |  Advertised with MELG-ID - 25/192000 
      | Database |   |  [SRLG-ID 25; Shared Resource ID 192000]    
      ------------   |_____________________________________________   
                 
        [B] ++++++++ [E]                      [J] +++++++++ [C] 
                         ++++            +++++  
                             +++      +++         
                                ++++++     
                             +++      +++ 
                         ++++            +++++ 
        [A] ++++++++ [F]                      [I] +++++++++ [D]  
              

  Figure 2b: Client TE Database - Mutually Exclusive Virtual TE Links 

      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 4]

Internet-Draft                   MELG                     February 2013 
         

   Now consider augmenting the Client TE topology by creating a couple 
   of Virtual TE Links across the optical domain. The potential paths 
   in the WDM network catering to these two virtual TE links are as 
   shown in Fig 2a and the corresponding augmented Client TE topology 
   is as illustrated in Fig 2b. 

   In this particular example, the potential paths in the WDM layer 
   network supporting the Virtual TE Links not only intersect, but also 
   require the usage of the same resource (lambda channel 192000) on 
   the intersection. Because the Virtual TE Links depend on the same 
   uncommitted network resource, only one of them could get activated 
   at any given time. In other words they are mutually exclusive. The 
   same scenario is encountered when the potential paths depend on a 
   common physical resource (e.g. transponder, regenerator, wavelength 
   converter, etc.) that could be used by only one Server Network 
   Domain LSP at a time. 

   For a Client Network Domain path computation function (especially a 
   centralized one capable of concurrent computation of multiple paths) 
   it is important to know the existence of such mutually exclusive 
   relationship between Virtual TE Links. Absent this information, 
   there exists the risk of yielding erroneous concurrent path 
   computation results where only a subset of the computed paths can 
   get successfully provisioned. This document introduces the concept 
   of Mutually Exclusive Link Group to address this problem. 

3. Mutually Exclusive Link Group 

   The Mutually Exclusive Link Group (MELG) construct defined in this 
   document has 2 purposes 

   - To indicate via a separate network unique number (MELG ID) an 
     element or a situation that makes the advertised Virtual TE Link 
     belong to one or more Mutually Exclusive Link Groups. Path 
     computing element will be able to decide on whether two or more 
     Virtual TE Links are mutually exclusive or not by finding an 
     overlap of advertised MELGs (similar to deciding on whether two or 
     more TE links share fate or not by finding common SRLGs) 
           
   - To indicate whether the advertised Virtual TE Link is committed or 
     not at the moment of the advertising. Such information is 
     important for a path computation element: Committing new Virtual 
     TE links (vs. re-using already committed ones) has a consequence 
     of allocating more server layer resources and disabling other 
     Virtual TE Links that have common MELGs with newly committed 
     Virtual TE Links; Committing a new Virtual TE Link also means a 
      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 5]

Internet-Draft                   MELG                     February 2013 
         

     longer setup time for the Client LSP and higher risk of setup-
     failure.  

4. Protocol Extensions 

4.1. OSPF 

   The MELG is a sub-TLV of the top level TE Link TLV. It may occur at
   most once within the Link TLV. The format of the MELGs sub-TLV is 
   defined as follows: 

   Name: MELG 
   Type: TBD 
   Length: Variable 
                     
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |            Sub-TLV Type       |            Sub-TLV Length     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    VTE-Flags (16 bits)     |U |  Number of MELGs (16 bits)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 MELGID1 (64 bits)                             | 
   |                 MELGID2 (64 bits)                             | 
   |                ........................                       | 
   |                 MELGIDn (64 bits)                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        
   Number of MELGs:              number of MELGS advertised for the  
                                 Virtual TE Link; 
   VTE-Flags:                    Virtual TE Link specific flags; 
   MELGID1,MELGID2,...,MELGIDn:  64-bit network domain unique numbers  
                                 associated with each of the advertised  
                                 MELGs    
         
   Currently defined Virtual TE Link specific flags are: 
      U bit (bit 1): Uncommitted - if set, the Virtual TE Link is 
      uncommitted at the time of the advertising (i.e. the server layer
      network LSP is not set up); if cleared, the Virtual TE Link is 
      committed (i.e. the server layer LSP is fully provisioned and 
      functioning). All other bits of the "VTE-Flags" field are 
      reserved for future use and MUST be cleared. 

         

      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 6]

Internet-Draft                   MELG                     February 2013 
         

   Note: A Virtual TE Link advertisement MAY include MELGs sub-TLV with 
   zero MELGs for the purpose of communicating to the TE domain whether 
   the Virtual TE Link is currently committed or not. 

4.2. ISIS 

   The MELG TLV (of type TBD) contains a data structure consisting of: 

      6        octets of System ID 
      1        octet of Pseudonode Number 
      1        octet Flag 
      4        octets of IPv4 interface address or 4 octets of a Link  
               Local Identifier 
      4        octets of IPv4 neighbor address or 4 octets of a Link  
               Remote Identifier 
      2        octets MELG-Flags 
      2        octets - Number of MELGs 
      variable List of MELG values, where each element in the list 
               has 8 octets 
               
   The following illustrates encoding of the value field of the MELG 
   TLV. 
         
         
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           System ID                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        System ID (cont.)      |Pseudonode num |    Flags      | 
   +-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 
   |          Ipv4 interface address/Link Local Identifier         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Ipv4 neighbor address/Link Remote Identifier         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    VTE-Flags (16 bits)     |U |  Number of MELGs (16 bits)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 MELGID1 (64 bits)                             | 
   |                 MELGID2 (64 bits)                             | 
   |                ........................                       | 
   |                 MELGIDn (64 bits)                             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        

      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 7]

Internet-Draft                   MELG                     February 2013 
         

The neighbor is identified by its System ID (6 octets), plus one octet 
to indicate the pseudonode number if the neighbor is on a LAN 
interface. 
         
The least significant bit of the Flag octet indicates whether the   
interface is numbered (set to 1) or unnumbered (set to 0). All other 
bits are reserved and should be set to 0. 
      
The length of the TLV is 20 + 8 * (number of MELG values). 
      
The semantics of "VTE-Flags", "Number of MELGs" and "MELGID Values" are 
the same as the ones defined under OSPF extensions.  
      
The MELG TLV MAY occur more than once within the IS-IS Link State 
Protocol Data Units. 
         
5. Security Considerations 

   TBD 

6. IANA Considerations 

6.1. OSPF 

   IANA is requested to allocate a new sub-TLV type for MELG (as 
   defined in Section 4.1) under the top-level TE Link TLV. 

6.2. ISIS 

   IANA is requested to allocate a new IS-IS TLV type for MELG (as 
   defined in Section 4.2). 

7. Normative References 

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate 
                Requirement Levels", BCP 14, RFC 2119, March 1997. 
         
   [RFC4202]    K.Kompella, Y.Rekhter, "Routing Extensions in Support 
                of Generalized Multi-Protocol Label Switching (GMPLS)",  
                RFC4202, October 2005. 
         
   [RFC6001]    D.Papadimitriou, M.Vigoureax, K.Shiomoto, D.Brungard  
                and JL. Le Roux, "GMPLS Protocol Extensions for Multi- 

      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 8]

Internet-Draft                   MELG                     February 2013 
         

                Layer and Multi-Region Networks", RFC 6001, October  
                2010. 
         
8. Acknowledgments 

   Chris Bowers [cbowers@juniper.net] 

Authors' Addresses 

   Vishnu Pavan Beeram 
   Juniper Networks 
   Email: vbeeram@juniper.net 
         
   Igor Bryskin 
   ADVA Optical Networking 
   Email: ibryskin@advaoptical.com 
         
   John Drake 
   Juniper Networks 
   Email: jdrake@juniper.net 
         
   Gert Grammel 
   Juniper Networks 
   Email: ggrammel@juniper.net 
         
   Wes Doonan 
   ADVA Optical Networking 
   Email: wdoonan@advaoptical.com 
         
   Manuel Paul 
   Deutsche Telekom 
   Email: Manuel.Paul@telekom.de 
          
   Ruediger Kunze 
   Deutsche Telekom 
   Email: Ruediger.Kunze@telekom.de 
          
   Oscar Gonzalez de Dios  
   Telefonica 
   Email: ogondio@tid.es 
         
   Cyril Margaria 
   Nokia Siemens Networks 
   Email: cyril.margaria@nsn.com 
      
      
      
Beeram, et al          Expires August 18, 2013                 [Page 9]

Internet-Draft                   MELG                     February 2013 
         

         
   Friedrich Armbruster 
   Nokia Siemens Networks 
   Email: friedrich.armbruster@nsn.com 
          
   Daniele Ceccarelli 
   Ericsson 
   Email: daniele.ceccarelli@ericsson.com 
         

      
      
      
Beeram, et al          Expires August 18, 2013                [Page 10]