[CCAMP] Overlay model framework v2

[Daniele Ceccarelli <[e-mail]>]

Dear overlayers,

Please find below a new version (v2) of the framework summary reflecting the latest discussions. Again i hope i've captured all the comments around, sorry if anything is missing, in case just let me know what i missed.

BR
Daniele


+ Disclaimer:
 1. Packet opto integration is often considered but the work can be extented to any type of SC. Eg. TDM over LSC.

+ Terminology:
 1. Virtual Link: A virtual link is a potential path between two virtual or real network
 elements in a provider layer network  that is maintained/controlled in and by the provider
 domain control plane (and as such cannot transport any traffic/data and protected from being
 de-provisioned) and which can be instantiated in the data plane (and then can 
 carry/transport/forward traffic/data) preserving previously advertised attributes such as 
 fate sharing information.
 2.  Virtual Node: Virtual node is a collection of zero or more provider network domain
 nodes that are collectively represented to the clients as a single node that 
 exists in the customer layer network and is capable of terminating of access,
 inter-domain and virtual links.
 3. Virtual Topology: Virtual topology is a collection of one or more virtual or real provider
 network domain nodes that exist in the customer layer network and are interconnected
 via 0 or more virtual links.
 4. Overlay topology:  is a superset of virtual topologies provided by each of
 provider network domains, access and inter-domain links.
 5. Access Link: Link between OC and OE. GMPLS runs on that link. It can support
 any of the SCs supported by the GMPLS.
 6. CE (customer Edge): Something like the CN in RFC4208 teminology  but (i) receiving 
 virtual topology from the provider network and requesting the set up of one of them or
 (ii) requesting the computation and establishment of a path accordingly to given constraints
 in the provider network and receiving the parameters characterizing such path. (ii) == UNI.
 7. PE (provider Edge): Something like the EN in RFC4208 but able to deal with (i) and (ii) above.
 8. PE-CE interface (former ONI) : Interface allowing for signaling and routing messages
 exchange between customer overlay and provider network. Routing information consists on
 virtual topology advertisement. When there is no routing adjacency across the interface
 it is equivalent to the GMPLS UNI defined in 4208. Signaling messages are compliant with
 RFC4208. Information related to path carachteristics, e.g. TE-metrics, collected SRLG,
 path delay etc, either passed from CE to PE via signaling after the LSP establishment
 in the core network or from CE to PE to be used as path computation constraints, fall
 under the definition of signaling info and not routing info).
 9. CE-CE (former O-NNI): Interface on the links between different provider networks
 in the overlay model environment. Same features of the CE-PE apply to this interface. 

+ Statements
 1. In the context of overlay model we are aiming to build an overlay topology for
 the customer network domains  
 2. The overlay topology is comprised of:
    a) access links (links connecting client NEs to the provider network domains).
 They can be PSC or LSC.
    b) inter-domain links (links interconnecting server network domains)
    c) virtual topology provided by the provider network domains. Virtual Links
 + Virtual Nodes (TBD) + Connectivity Matrix (with a set of parameters e.g. SRLG,
 optical impairments, delay etc for each entry) describing connectivity between access links and virtual links.
 3. In the context of overlay model we manage  hierarchy  of overlay topologies
 with overlay/underlay relationships  
 4. In the context of overlay model multi-layering and inter-layer relationships
 are peripheral at best, it is all about horizontal network integration   
 5. The overlay model assumes one CP instance for the customer network and a separate
 instance for the provider network and in the CE-PE interface case the provider
 network also surreptitiously participates in the customer network by injecting
 virtual topology information into it.
 6. L1VPN (and LxVPN) in general is a type of service provided over the CE-PE interface
 (it falls under the UNI case as no routing adjacency is in place between CE and PE).


+ Advertisement models (to be detailed in dedicated document/documents)
 The CE-PE interface in the overlay model context foresees two types of advertisement
 models.(names still to be agreed)
A. Augmented UNI: The GMPLS UNI is defined in RFC4208 and augmented by
 a number of actived draft (references to various drafts to be added).
 The Augmented UNI is a particular type of CE-PE interface where only signaling messages
 are exchanged between CE and PE. Messages from CE to PE can include
 a set of parameters to be used by the PE as path computation constraints
 when computing a path in the provider domain network, while messages from PE
 to CE can include a set of parameters qualifying the LSP being established,
 like for example SRLG, delay, loss etc.
B. ONI: The GMPLS ONI is a CE-PE interface (this could be simply called with the
 general CE-PE interface term?) allowing the establishment of signaling and routing adjacency
 between CE and PE. Routing info passed from PE to CE comprise overlay topology information including
 (but not limited to) virtual links, connectivity matrices and access links with parameters qualifying
 each of them in terms of e.g. SRLG, loss, delay etc. Signaling information and procedures are
 compliant with RFC4208.

+ Open issues/questions
 1. PCE-PCEP - do we need to include considerations about PCE and PCEP into the overlay framework context?
 2. BGP-LS needs to be considered
 3. Should potentials be included? E.g. I2RS?
 4. Virtual links: wouldn't a different definition of virtual links avoid the advertisement of connectivity matrices (this is out of the fwk scope but within the advertisement models one)?
Take this example:
PE1-----CE1               CE2-----PE2
        CE1======VL1======CE2
        CE1======VL2======CE2
i.e. There are 2 VL connecting CE1 and CE2 that could be available for PE1 and PE2 to set up an adjacency in the customer domain. CE1 and/or CE2 can be blocking nodes so VL1 and/or VL2 are available only depending on the connectivity matrices of CE1 and CE2. Hence PEs need to be aware of both VL and connectivity matrices. My point is: if CE1 advertises to PE1 only the VL that his connectivity matrix allows to be connected to PE1 (e.g. VL1 only) and not all of them, it should be possible to avoid the connectivity matrices advertisement. 

 
===================================
DANIELE CECCARELLI  
System & Technology - PDU Optical & Metro 

Via E.Melen, 77
Genova, Italy
Phone [phone]
Mobile [phone]
[e-mail]
www.ericsson.com  

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer