NOBEL Technical Audit WP 4 Objectives & Achievements Brussels, March 08, 2006

1. NOBEL Technical AuditWP4 Objectives & AchievementsBrussels, March 08, 2006 Work Package 4 Network Management and Control/Protocols Monika Jaeger, T-Systems WP4

2. Nobel Objectives • To define requirements, architecture and solutions for core-metro IP-over-optical networks for broadband end-to-end services • To study advanced network functionalities such as multi-layer traffic engineering and multi-layer resilience • To make techno- and socio-economic analysis of core and metro case-studies • To find packet/burst switching techniques and technologies • To discover innovative solutions for the three network planes: management, control and data (transmission) • To define multi-service/multi-layer node architectures and to prototype the implementation of some selected node functionalities • To assess existing technologies, components and sub-systems • To integrate some test beds where to validate the project results WP4 WP4

3. WP4 Objectives To analyze and propose solutions to lower the Network Management and Control complexity in core and metro networks To develop management and control strategies/functions for the evolutionary NOBEL network scenarios and architectures To investigate a comprehensive set of practical management and control aspects, leading to more simplified and efficient solutions (to be communicated towards standardization) To design and perform ASON/GMPLS and management prototype implementations with experimental evaluations, in complement to the conceptual studies Overall WP4 goal: NOBEL short, mid, long-term network scenarios from WP1… … analyze and propose simplified strategies and collaboration of Network Management and Control Nobel Network Scenario WP4 WP4

4. Activity Summary • A4.1 - Network Management (NM) and Control/Protocol (CP) requirements and functional scope • A4.2 - Performance, fault management, fault localization, and QoS monitoring requirements and solutions • A4.3 - Inter-domain, multilayer NM , CP, and Service Management aspects • A4.4 - Standardization approaches, especially centralized vs. distributed implementation of NM and CP functions • A4.5 - NM and CP prototype function and design specification, implementation and test WP4

5. WP4 Partners Contributing partners • Alcatel CIT • T-Systems (WP4 coordinator) • Telecom Italia Lab • Siemens • Telefónica • Marconi Comm. S.p.A. • (Marconi ONDATA) • Scuola Sup. S. Anna Planned total Manpower for 2004 and 2005: 352 MM Telenor Lucent Nederland BV TeliaSonera CTTC Alcatel Italia ACREO France Télécom Ericsson WP4

6. AggregationArea IP/Optical Network Introduction Network Areas Core Area AggregationArea IP Multi-Technology/Service Access Area Multi-Technology/Service Access Area Trans-port Access • Business Customers • Mass production • DSL public • FTTx Aggregation • Efficient aggregation of multiple data streams in metro/regio area • Support of different services Core • High throughput at very low cost in backbone area • Optical technology • Scalability, open for growth WP4

7. WP4 Overall ViewReference Points and Domains Client (User) - A Network Provider - A Network Provider - B PPI UPI MP MP NMI-A = SubNetwork UNI-C UNI CP CP CP Intra-carrier E-NNI Inter-carrier E-NNI NMI-T CCI TP TP TP TP CP = Control Plane MP = Management Plane TP = Transport plane UNI = User Network Interface E-NNI = External Network Network Interface NMI-A = Network Management Interface, MP-CP NMI-T = Network Management Interface, MP-TP CCI = Connection Controller Interface UPI = User-Provider Interface PPI = Provider-Provider Interface Switched Connection Service • Voice/packet oriented management model • Transport oriented (SDH/OTH) management model • Hybrid management model WP4

8. Management Management Management Management Core and Metro Networks State of the Art • Multilayer infrastructure … • Circuit and packet based switching technologies • Aggregation and grooming • … with independent network management • Service configuration • Fault management • Protection and Restoration… • … some layershave control plane • IP/MPLS deployed • ASON/GMPLS? • Ethernet? IP GigE SDH WDM WP4

9. ASON/GMPLS Control Plane Benefits CapEx Reduction OpEx Reduction • Less backup capacity with restoration and shared mesh protection (up to 30 %) • Reduced over-provisioning with resource efficiency due to dynamic resource assignment • Enhanced traffic engineering capabilities • Efficient aggregation and grooming • Automatic discovery mechanisms • Automatic provisioning, TE and resilience • Alarm correlations and reductions • Offloaded and simplified management • Simplified automated inter-working with other administrative domains New services (ASON specific) Simpler Network Integration • ASON controls point-to-point connectivity for L1/L2-services, over single and multiple domains • Resilience of L1 and L2 services • Offers support for flexible VPN services • Ethernet services based on GFP, LCAS • ASON as server layer of IP creates (IP topology), redirects (resilience) and modifies (bandwidth) dynamically links between IP/MPLS/GMPLS routers • Simplified integration of new equipment • Interoperability at control plane level between different vendor implementations at UNI and NNI interfaces • Increased scalability for IP • Simplified Inter-working with MPLS and Ethernet WP4

10. Control Plane Issues in WP4Multi-Service/Layer/Domain Scenarios Multi-vendor/-technology functional architectures and generic modeling concepts for multi-domain ASON/GMPLS networks, managed by TMF-MTNM: Main objectives: • Identify architecture and control suited for specific service scenario • No single network architecture and control scenario fits all services and business models • Identify simplified control and management solutions • Resolve general interoperability issues raised by NOBEL scenarios (provided in WP1) • Fine tune protocols as well enable converge toward real exploitation perspectives • Verify concepts through implementation and test WP4

11. Control Plane Issues in WP4 Scope and Results Detailed objectives: • Horizontal integration: Inter-domain collaborative mechanisms • Cooperation between MPLS-GMPLS and migration scenarios • Compatibility issues between ASON and GMPLS concepts and paradigms • Propose enhancements to an IP-based (end-to-end) signaling protocol • Inter-carrier interworking at E-NNI • Vertical integration: Intra-domain cooperation between different data planes • Multilayer networks and common control plane, including TE • Unified Traffic Engineering in GMPLS networks • Layer 2 LSP and GMPLS for Ethernet • Path Computation Element (PCE), and its applications, for (G)MPLS • Operational aspects for the GMPLS stack of protocols • Control Plane dimensioning and performance analysis • Restoration in multilayer and multi-domain networks WP4

12. Control Plane Issues in WP4NG-SDH, GFP, VCAT, LCAS • The integration of NG-SDH into the control plane could provide benefits regarding: • Non-disruptive bandwidth modification • Increase the resilience of the network • To accomplish this, control plane should be properly enhanced: • Support of multi-layer calls. • Call and connection separation and support of calls composed of multiple connections. • Bandwidth modifications • End-to-end path diversity WP4

13. Control Plane Issues in WP4NG-SDH, GFP, VCAT, LCAS • Support of multi-layer calls: • All the connections at the server layer should be created before the connection at client layer. This sequence allows also the correct coordination between the control plane and the SDH VCAT/LCAS procedures • Call and connection separation: • Two approaches from ITU-T and IETF, whose differences are more in the form than in the substance. • ITU-T: a new object (CALL_ID) in two forms (Globally unique, operator specific) • IETF: use of unused fields in already existing objects • Bandwidth modifications • Modify bandwidth of existing calls (Ethernet) • Add new connections to existing calls (SDH) • End-to-end path diversity • In the scope of the work of the PCE Wg WP4

14. Information modellingObjectives and approach Based on requirements for (automating) the CP - MP interaction • Considering and harmonizing existing functional architectures and models: • ITU-T, e.g. G.8080, G.805, G.7718, M.3100, and TMF (MTNM 608),and previous IST projects LION, WINMAN • IETF GMPLS, and MPLS/GMPLS MIBs To develop an information model for CP – MP collaboration, that enables and supports: • End-to-end service establishment and management • Efficient, flexible, and adaptive management and control mechanisms • Multilayer, multi-technology, multi-domain networks • Innovative Policy-based management framework • Focusing first on a model of managed entities representing the CP itself, its components, and capabilities, and how CP components are related To derive a policy information model for enabling policy-based management and configuration of the CP itself and for improving the TP operational management via the CP Work in progress – work to continue in NOBEL 2 WP4

15. MP . . . NMI-A CP . . . Relationship of Information Modelling Standards and IST Projects Results Winman use case approach NOBEL approach + integration of existing results info model Focus of IM work modeling approach, info model and architecture NEL view info model and use cases NL view ITU-T NEL view Standardisation TMF IETF WP4

16. CP Node and CP Elementexample configuration (not IM as such) WP4

17. Routing Controllers in CP Element and CP domain WP4

18. Information modelling – Further work (NOBEL 2) • Continue the requirements analysis and design phases with review of relevant sources to assess, update, and improve the current model • Open issues and areas not jet covered by the model: • E.g., management capabilities related to TE, resilience, and path computation, VPN, accounting, and SLA assurance • To derive a policy information model to enable policy-based management and configuration of CP mechanisms and the TP via management of the CP • The role and relationship of the management information model and the policy information model must be carefully considered • To investigate and extend existing policy information models(E.g. IETF PCIM/PCIMe, QPIM) • Contribute to standardisation WP4

19. Implementation Activities in WP4Objectives and Realization A4.5 - NM and CP prototype function and design specification, implementation and test Objectives: • Implementation of selected features specified in WP4 • Integration into prototypes and emulators • Lab experiments, function verification and performance measurements • Overall conclusions and recommendations derived from experiment results • Integration into testbeds for field trials and interoperability tests in WP8 Realization: • Eight partners implement new features in prototypes and emulators partly reused from internal or other EU projects • Focused on UNI (8x), E-NNI (3x) , hybrid performance monitoring (1x), XMP-based multi-protocol frameworks (1x) • Delivery to four testbeds in Spain, Sweden and Italy WP4

20. SDH/OTH Prototypes UNI implementations (x4) Optical node, OTH and SDH E-NNI implementations (x3) Optical node, OTH and SDH Optical peformance monitoring implementation OTH Protocol controller implementation Based on an XLM parser/formatter Emulators & Simulators GMPLS UNI implementation for an ASON/GMPLS simulator (x2) E-NNI implementation on a simulator CCI, UNI and NNI implementation on a simulator Achievements Planning & Specification • Selection of implementation features: (GMPLS) UNI, E-NNi, XML protocol controller, optical performance monitoring • Concept and design specification for the prototype, emulators and simulators • Test specification WP4

21. Developed Prototypes WP4

22. WP4 Deliverables and Publications (Y2) • D18 “Conclusions on NM and CP functional scope and standardization approaches; NM and ASON prototype functional scope”(March 2005) • D25 “Solutions for inter-domain and multi-layer NM & CP and Service Management concepts; NM and ASON prototype functional and design specification and test plan” (September 2005) • D33 “Conclusions on Network Management and Control solutions supporting broadband services for all” (February 2006) WP4

23. WP4 Deliverables and Publications II (Y2) • Guillaume Juillot, Martin Nathansen, Cyril Margaria, and Andreas Iselt; "Emulation in GMPLS-controlled Optical Transport Networks"; ONDM2005, Milano, Italy, February 2005. • G. Juillot, C. Margaria, M. Nathansen, A. Iselt; "Emulation of GMPLS controlled Networks"; NOC2005, London, England, July 2005. • M. Vigoureux, B. Berde, L. Andersson, T. Cinkler, L. Levrau, M. Ondata, D. Colle, J. Fernandez-Palacios, M. Jäger; “Multilayer traffic engineering for GMPLS-enabled networks”; IEEE Communications Magazine, ISSN 0163-6804/05, Vol. 43, Nr. 7, July 2005, pp. 44-50. • B. Berde, M. Canali, P. Castoldi, M. Jäger, L. Levrau, H. Lønsethagen, A. M. Mazzini, M. Nathansen, J. Gonzales Ordàs; "Network Management and Control for Intelligent and Agile Optical Networks"; ONDM2005, Milano, Italy, February 2005. WP4

24. WP4 Deliverables and Publications III (Y2) • C. Pinart, A. Amrani, G. Junyent; “Design and experimental implementation of a hybrid optical performance monitoring system for in-service SLA guarantee”; 9th IFIP/IEEE International Symposium on Integrated Network Management (IM 2005), Nice, France, May 16-19 2005. • C. Pinart, R. Martínez, G. Junyent; “Experimental implementation of dynamic in-service performance monitoring for lambda services”; 31st European Conference on Optical Communications (ECOC 2005), Glasgow, UK, September 25-29 2005. • L. Valcarenghi, L. Foschini, F. Paolucci, F. Cugini, P. Castoldi; "Topology Discovery Services for Monitoring the Global Grid"; IEEE Communication magazine special issue on "Optical Control Plane for Grid Networks: Opportunities, Challenges and the Vision", to appear, March 2006. WP4

25. WP4 Highlights and Self AssessmentReached Objectives Year 2 • Definition of requirements, key characteristics, architectures and solutions of multi-service/layer/domain network management and control • Analysis of functional architectures; recommendations on generic modelling concepts and key features of ASON/GMPLS • Network service requirements, w.f.o. Layer 1, 2, 3 VPNs; Control and management scenarios of storage, broadcaster and grid applications as users of VPN services; CP enabled solutions for VPN services • Control plane issues for TE in multilayer/multi-technology networks • Inter-carrier interworking scenarios; identification of functional requirements related to different business models • ASON-GMPLS convergence issues and required harmonization actions • MPLS-GMPLS interworking, MPLS-GMPLS migration scenarios • Information Modeling requirements with focus on the interaction of the control plane and management plane • Implementation of key functions of network management and control and performance of selected tests, in cooperation with WP8 WP4

26. WP1/WP4 Common Activities • VPN service scenarios and solutions • Service Supportive Networks WP4

27. UNI UNI Customer 2 Customer 1 is connected to UNI can connect to has visibility Customer 1 Customer 2 VPN Reference Model Shared or dedicated resources • Transport plane • Physical port based (dedicated) • Logical port based (dedicated) • Node based (dedicated) • Connection based (shared) • Closed User Group (shared) • Control plane • One CP instance per VPN (dedicated) • One global CP instance with optional resource partitioning (shared) WP4

28. VPN – general investigations • L1/ L2/ L3 VPNs that are based on advanced control plane functions, and its related management framework • Investigate types of L1 VPNs and related UNI/ NNI functionalities • Study inter-domain issues (intra-/inter-carrier) in L2/L3 VPNs • Capture management requirements for novel VPN services • Propose a potentially homogeneous solution to (control plane-based) Layer 1, 2, and 3 VPNs, and their management issues with reference to the NOBEL scenarios • Specify CE/PE management functions at customer and provider side: definitions, functionality, architectures, Information Model • Identify VPN implementation issues WP4

29. State of the art • L3 VPNs • Mature technology • Available for several years • L2 VPNs • Many commercial offerings • Most specs ready for publication • L1 VPNs • No (known) provider offering them • No (full) support from vendors • Timeframe for availability: Q2-2007 • IETF • L2 and L3 VPN working groups • RFC3809 “Generic Requirements for Provider Provisioned Virtual Private Networks” • L1 VPNs not (yet) in CCAMP charter • ITU-T • Study Group 13, Question 2 • Published standards • Y.1311: Network Based VPNs - Generic Architecture and Service Requirements • Y.1312: L1 VPN generic requirements and architectures • Y.1313: L1 VPN service and network architectures • Work in progress • Y.vpn-decomp: Generic VPN Functional Decomposition • Y.vpn-qos: QoS support for VPN services – Framework and Characteristics • OIF • No support for VPNs in UNI 1.0 or UNI 2.0 • Planned for an unspecified future release WP4

30. LxVPN LxVPN service 1 (e.g. Video) service 2 (e.g. SAN traffic) x={1,2,3} L1VPN Provider Network Multiple services VPNs WP4

31. VPN Service ScenariosJoint WP1-WP4 work • VPNs for broadcasters • Contribution and distribution network for standard TV, high definition TV etc. • Study of L1-VPNs and L2-VPN implementation options • VPNs for storage applications • Remote vaulting and backup • Synchronous and asynchronous disk mirroring • Storage on demand needs flexible resource, high sensibility to latency, packet loss and BER • VPNs for GRIDs • Studies impact of overlay networks in VPNs • Virtualization of network, complements processing and storage virtualization • Very high bandwidth needs, flexibility WP4

32. Interaction between customer and network provider: Interfaces a) Advanced reservation (I) b) Advanced reservation (II) Business Plane/ Service Plane Business Plane/ Service Plane WebInterface Management Plane User Network Management Plane User Network missing CP:means only, no functionality visible for the user Business Plane/ Service Plane c) Dial In Management Plane User metwork WP4

33. L1 – L2 VPN ComparisonFirst results • Resource sharing and business process outsourcing enabled by extended VPN services is added value to customer • But, VPNs with broad customer control may reduce “vertical range of manufacture” WP4

34. Service Supportive Networks Motivations & Objective Motivations • It is not possible to transparently trigger all network services defined in NOBEL using the UNI (e.g. set-up of advanced network services such as VPNs) is done via the Management Plane • Applications have practically no mean to shape connectivity according to their needs via UNI • Even if an evolution of the UNI can be conceived, this evolution should be tailored in different flavors depending on the type of controlled transport network (UNI is technology-dependent) Objective • Introduction of automatic operation in the NOBEL network for triggering network services. • Define service invocation mechanisms that allow service invocation by applications envisioning short and medium/long term scenarios. • Define interfaces for the short term scenario (on request) and long term scenario (on-demand) WP4

35. Application to Network interaction • Application End Point (AEP) includes management process & core process • On-request: User to provider Interface (UPI), interface between AEP and client MP • On-demand: User to service interface (USI), interface between AEP and Service Elements • Service Element (SE): entity capable of triggering CP solicited by AEP via USI WP4

36. UPI/USI requirements & Open Issues UPI main requirements • Shall support machine-based interaction as an evolution from existing human-based interaction • Shall support control of connectivity from the management platform of the customer application USI main requirements • Shall enable end-user functions or AEPs to access services provided by different administrative network domains and regardless of the access network technology • Shall support both executive or informative services on an administrative domain • Shall support the transparency of applications across multiple domains • Shall allow on-demand interactive services with real time constraints • Shall support session-based services (e.g., high-definition video-telephony) and non-session-based services (e.g.,e-Business transactions) as well Open Issues • Mapping of abstract service request to transport technology specific network services. • The engineering of a “percolation” mechanism of a service invocation message coming from an application into a resource request understandable by an ASON/GMPLS metro networks WP4

37. Long-term scenario (2) • User-controlled service provisioning provided by dedicated Service Entities (SE)s through USI (distributed approach), e.g. on-demand VPN • Transparent service provisioning based on signaling protocol among SEs WP4

38. Service Supportive Networks Approach First objective of Service TF: finalize the short/medium term scenario, i.e. demonstrate an enhancement of NOBEL architecture supporting a service interface beyond the UNI. • Primary focus on application services that are strictly related to and dependent on network services (e.g. storage applications). • What features supported by UPI for network service set-up (Sant’Anna, Telenor, .… • What are the UPI limitations that make us call for the long term approach outlined below (Sant’Anna, Telenor, .... WP4

39. Potential Follow Up Activities in NOBEL II Second objective of Service TF (not expected to complete in NOBEL I) finalize the long-term scenario, i.e. build a flexible and future proof service oriented NOBEL network architecture supporting application/user services. In NOBEL II Sant’Anna will also contribute to WP1, possibly split work between WP1 and WP4 and collaboration with Signaling TF and VPN TF: • Focus on automatic/intelligent (i.e. application-network cooperative) set-up of network services based on a request of an application/user service (Sant’Anna, …… • Define functionalities, message exchange, architecture of the SEs in view of the previous point, i.e. try to shape the so-called “service plane” (Sant’Anna, …. • Define supported primitives over the USI to achieve the goal (Sant’Anna, ….. WP4