Re: [CCAMP] Overlay model framework v2

[Daniele Ceccarelli <[e-mail]>]

Ok, sounds good.

BR
Daniele 

>-----Original Message-----
>From: Igor Bryskin [mailto:[e-mail]] 
>Sent: mercoledì 16 gennaio 2013 18.50
>To: Daniele Ceccarelli; CCAMP
>Subject: RE: Overlay model framework v2
>
>Daniel,
>One correction:
>VN may represent a fraction of a real node. This makes 
>possible for the network to advertise a blocking PE as a set 
>of non-blocking PE and thus alleviate the client path computer 
>from dealing with blocking PEs.
>
>Igor
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Daniele Ceccarelli
>Sent: Wednesday, January 16, 2013 10:33 AM
>To: CCAMP
>Subject: [CCAMP] Overlay model framework v2
>
>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  
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>