ASTN enhancement for improved service support

1. ASTN enhancement for improved service support Piero Castoldi, Fabio Baroncelli, Barbara Martini WP4 NOBEL Meeting Munich, Germany June 13-15, 2005

2. Outline Motivations and definitions Analysis of the current UNI capabilities Architectural and functional proposal to improve the service support at the UNI interface Proposal for issues to be dealt within NOBEL Input from MEF: Ethernet as a Service (included only for offline discussion) Acknowledgements: comments received from Massimo & Andrea (AI)

3. Motivation (1) – Functional improvement in service support BML/ SML NML CP (Network/Element) EML Management Plane (e.g. TMN) (Centralized) Control Plane (Distributed) Architectural state of the art: 1a) lack of (distributed) service functionalities in the Control Plane (e.g. ability to build complex VPN topologies, or point-to-point VPNsnot issued by the ingress node, interactive dialogs at the UNI) 1b) some service functionalities missing in the MP at SML level (e.g. collection of charging records for billing, easy Policy Management & SLS)

4. Motivation n. 2 – Enhancement of client-ASTN interaction State of the art of the client-ASTN adaptation features: 2a) Data framing adaptation (at the TP layer) is dependent on client network type, (connectivity adaptation), currently performed by the UNI statically. 2b) Provisioning adaptation is currently realized by direct interaction between the client (UNI-C) and ASTN CP nodes (UNI-N). 2c) No service virtualization is present, i.e. the possibility of issuing coarse-granularity network primitives at the client side and having them translated into fine-granularity technology-dependent primitives understood by the CP nodes

5. Analysis of the current UNI and client-ASTN interaction • UNI / UPI provides service requests (e.g. Call, a simple connectivity service) • UPI is used mainly for service issues (e.g. SLA activation/modification/deletion, assurance, billing) but also for e.g. soft permanent connection activation. OS-to-OS interface ASTN MP UPI NMI-A Signaling MP CP CP UNI-N UNI-C UNI CCI CCI NMI-T Data TP TP Client network • The figure is compliant with D2 apart from some refinements at the client side • UPI and UNI replaced by PPI and I/E-NNI for ASTN-to-ASTN interfaces

6. SO-ASTN Service Plane (SP) Service Plane as the new adaptation plane TP + MP + CP • In order to answer motivation 1 and 2, we propose to enhance ASTN as follows: • place in edge nodes *only* of the ASTN some extra features (distributed) • we name “service plane” the set of distributed service features placed in edge nodes • we name SO-ASTN (Service Oriented) the resulting new ASTN

7. “Service Plane”in Network Provider • We confirm the architecture • We want to define roles and interfaces Positioning “Service plane” “Service plane” Client Network Client Network Management Plane Management Plane NMI-A NMI-A Control Plane Control Plane NMI-T CCI CCI NMI-T Transport Plane Transport Plane Network Provider Network Provider NOBEL Scope From SSSUP Stockholm presentation Sept. 2004

8. What gaps we would like to fill? (functional) Service Level MP Network Level CP Element Level

9. Service Virtualization Provisioning Adaptation Technology- dependent service Request Basic service Client network Complex service What gaps we want to fill? (architectural) Client Network: node that requests services from the ASTN. Complex service: coarse-granularity (connectivity) and possibly interactive service expressed in application-like terms (e.g. request to set-up a VPN with complex topology or receive information about the VPN topology VPN, but also a storage back-up service) Basic service: fine-granularity connectivity service expressed in abstract terms but with one-to-one correspondence with current or future UNI services Technology-dependent service: connectivity services provided by the current or future UNI standards

10. NMI-S SP MP SP Service Interface Service Virtualization Provisioning Adaptation SNI CP UNI-C Connectivity adaptation Introduction of an improved service support into ASTN SO-ASTN UPI BML/ SML MP NML NMI EML NMI-A Signaling CP UNI-N UNI Client CCI NMI-T CCI TP TP Data Client network • Service virtualization block (can be customized via the MP through a Policy Management interface NMI-S) translates a complex service into a basic service depending on client needs (bandwidth, QoS, reliability specifications) • Provisioning adaptation block translates a basic service into one or more technology- dependent service, understood by a CP node, and depending on provider availability (network capability,traffic matrix, overbooking policies) • Connectivity Adaptation is an intersection block between TP and SP and deals with (possibly automatic/dynamic) data framing SP = Service Plane SNI = Service to Network Interface NMI-S = Network Management Interface Service ALL NEW INTERFACES ARE TENTATIVE.

11. MP CP UNI-C Are there standard Interfaces? (Slide TMF-biased) SO-ASTN MTOSI BML/ SML SP MTOSI SP MP MTOSI NML EML NMI Service Virtualization Provisioning Adaptation MTNM MTNM Signaling CP UNI-N OIF or GMPLS UNI CCI NMI-T CCI TP Connectivity adaptation TP Data Client network • MTOSI group could currently covers UPI/PPI specs and could cover the NMI-S and service interfaces of SO-ASTN • MTNM group could currently covers NMI-A specs and could cover the SNI of SO-ASTN • Question: can we separate two entities: the Service Provider and the Transport Provider? • What use cases can we identify here?

12. Centralized MP, distributed CP and SP MTOSI BM/SM DSC MTOSI NM MTNM MTNM CPC Adapter EM DSC DSC CPC Network CPC CPC DSC CPC CPC DSC CPC CPC CPC CPC CPC DSC CPC

13. Resource DB Provisioning Adaptation Service Virtualization Serv. Interf Connectivity adaptation Distributed Service Functionality Metro CWDM A Scenario MPLS/IP Core Router SDH/WDM Backbone Service-Oriented Metro-Core (SO-ASTN) Feeder/ Metro POP Storage C L I E N T N E T W O R K PE, BRAS ATM Switch L2/L3 SWITCH Edge Router Media Gateway Optical Metro-Access Network GbE SDH PSTN, xDSL,WiFi, Optical Access PC, Modem, Router, WiFi Access Point, PDA CPE

14. Open issues for possible inclusion in D25 and D33 • Service virtualization • Definition of what a complex service could be • Definition of Virtualization mechanism • OS-to-OS interface enhancement for • SLA management • Charging management • Provisioning adaptation • Signaling adaptation (IETF reference, job covered by NOBEL Signaling working group) • Issues on management: • Conversion of technology specific requirement (protection, QoS) • Data network managed via MPLS vs. SDH/WDM managed via GMPLS • Harmonization of end-to-end management wrt network capability (performance monitoring, fault management) • Connectivity adaptation • Identify convergence transport layers

15. Impact from/to standards (currently TMF biased) • Service virtualization • Virtualization mechanism -> ??? • OS-to-OS interface enhancement -> MTOSI • SLA management • Charging management • Provisioning adaptation • Signaling adaptation (IETF reference, job covered by Signaling TF) -> IETF, OIF • Issues on management: -> MTOSI, MTNM, and maybe ITU-T • Conversion of technology specific requirement (protection, QoS) • Data network managed via MPLS vs. SDH/WDM managed via GMPLS • Harmonization of end-to-end management wrt network capability (performance monitoring, fault management) • Connectivity adaptation • Identify convergence transport layers -> Ethernet?

16. Conclusions Identified some missing features of current ASTN Proposed some new functions to improve service support in ASTN Proposed new functional blocks for ASTN in the Service Plane Service Plane is distributed, but only at edges Identified a possible set of interfaces Can we start a new Service TF (possibly jointly with WP1)?

17. Input from MEF Ethernet as a Service

18. Ethernet as a Service • Ethernet’s origins in the Enterprise • Used as a LAN connectivity technology • Just plug it in and start using it • Ethernet’s new usage as a Service • Requires “service attributes” like other MAN / WAN services • Ethernet UNI, Ethernet “VC”, Service Performance, etc Same Ethernet technology just used in a new way

19. Ethernet Service Benefits • Ease of use • Widely available, well understood technology • Simplifies network operations (OAM&P) • Cost Effectiveness • Widespread use of Ethernet interface • Purchase bandwidth only when needed • Flexibility • Single UNI can connect to multiple services • Internet, VPN, Extranet supplier, Storage Provider • Bandwidth can be added in 1Mbps increments

20. Ethernet Service Model

21. Ethernet Virtual Connection (EVC) • An EVC is an association of two or more UNIs • A given UNI can support more than one EVC • A frame sent into an EVC can be delivered to one or more of the UNIs in the EVC other than the ingress UNI • It MUST NOT be delivered back to the ingress UNI • ItMUST NOT be delivered to a UNI not in the EVC • An EVC is always bi-directional in the sense that Service Frames can originate at any UNI in an EVC

22. UNI UNI Point-to-Point EVC

23. Multipoint-to-multipoint EVC UNI UNI

24. How the MEF defines an Ethernet Service • A service is defined via • Service Type • Service Attributes • Service Attribute Parameters

25. Ethernet Line (E-Line) Service Type Point-to-Point EVC IP Video Servers IP Voice Service Multiplexed UNI UNI IP PBX CE Data IP Video CE IP Voice UNI CE Data Point-to-Point EVC

26. Ethernet LAN (E-LAN) Service Type Multipoint-to-Multipoint EVC Servers IP Voice UNI UNI Data IP PBX CE CE IP Voice IP Voice UNI CE UNI CE Data Data