1 / 30

MAINS (Metro Architectures enablINg Subwavelengths)

MAINS (Metro Architectures enablINg Subwavelengths). WP3 Control Plane and Service-Network interface development. Nextworks team UAM team MAINS 1 st EC Technical Review Brussels, March 24 th 2011. Contents. MAINS GMPLS control plane overview Macro objectives

emele
Download Presentation

MAINS (Metro Architectures enablINg Subwavelengths)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MAINS (Metro Architectures enablINg Subwavelengths) WP3 Control Plane and Service-Network interface development Nextworks team UAM team MAINS 1st EC Technical Review Brussels, March 24th 2011

  2. Contents • MAINS GMPLS control plane overview • Macro objectives • MAINS GMPLS network reference points • Sub-wavelength network resources modelling • Sub-wavelength signalling & routing • MAINS Path Computation • GMPLS protocols extensions • MAINS extensions to OIF-UNI • MAINS GMPLS implementation • MAINS data plane overview • Interface specification • Preliminary results

  3. MAINS GMPLS control plane: macro objective [1] Specification and prototype development of an enhanced GMPLS control plane for the metro optical flow/packet transport Technical challenges Sub-wavelength switching granularity/capability support New service logics for connections setup & routes computation Routing and signalling extensions to standard GMPLS protocols Interoperation of OPST and TSON regions under a common enhanced GMPLS instance OPST ring and TSON physical nodes configuration through a uniform, flexible and cross-technology XML i/f (defined in WP2) Network Centric Service (NCS) provisioning i.e. combination of both network resources and IT resources

  4. MAINS GMPLS specs & prototypes Interface specification at control and transport plane WP1 D3.2 Implementation of service network interface D3.1 Service network interface specification D1.1 detailed signalling and routing protocols extensions D3.4 Implementation of GMPLS extension WP2 D3.3 Control plane extensions for GMPLS D3.5 Implementation of the centralized MAINS PCE D2.1 D2.3 Y1 delivered results Y2 planned outcomes

  5. MAINS GMPLS functional elements and interfaces Application Server MW interface To remote App.Server(s) Middleware MAINS NSI (MNSI) Subwavelength-enabled GMPLS CP MAINS PCE(s) MAINS E-NNI Gateway MNSI Gateway MAINS LER (edge) MAINS LSR (border/core) MAINS LSR (core) MAINS LSR (border) StandardGMPLS CP Data transport MAINS UNI MAINS I-NNI MAINS I-NNI MAINS I-NNI MAINS E-NNI CPE Ctrl Interface XML Interface XML Interface XML Interface XML Interface MPLS-TP/WSON Mesh OPST Ring TSON Mesh Access (LAN + last-mile) CPE Metro/regional segment Backbone segment

  6. MAINS service network interface: the MNSI • Allows the application layer to access sub-wavelength optical layer resources on-demand and at the granularity of optical packets/bursts • Represents the control part on top of the MAINS data transport interface (MAINS TP) • Provides network connectivity services based on the OIF UNI 2.0 standardized network services and the OGF NSI Architecture

  7. MNSI services and abstract messages

  8. MAINS GMPLS network reference points • MAINS UNI • built on top of the OIF UNI 2.0 • creation/deletion/modification of sub-wavelength network services • status enquiry/notification on the installed network services • MAINS I-NNI • based on the ITU-T ASON I-NNI interface (i.e. bidirectional signalling interface between control plane entities belonging to one or more domains having a trusted relationship) • creation/deletion/modification of calls and connections in the metro domain • status enquiry/notification on the installed calls and connections • sub-wavelength network resources announcement and discovery • MAINS E-NNI • responsible for requesting and establishing on-demand network services across different network domains • support of the IETF GMPLS multi-domain call signalling procedures • multi-domain routing based on the IETF hierarchical PCE model

  9. Control approaches for OPST/TSON OPST ring the internal OPST transport network resources are uniquely managed and configured by the custom OPST control plane a single MAINS GMPLS entity for the whole OPST ring The single MAINS GMPLS controller manages the OPST ring as a “virtual” Ethernet switch equipped with: a set of 10Gbps Ethernet client-access ports a set of 10Gbps Ethernet OPST/TSON interconnection ports TSON mesh direct interaction between the MAINS GMPLS instance and the per-node TSON control plane instance full access and visibility of nodes and links in the mesh a dedicated controller for each TSON node can be deployed

  10. TSON resource modelling

  11. Aggregated sub-wavelength network resource description • Introduce specific TSON signal types • TSON-10µs: statistical time division multiplexing of a wavelength with 10µs fixed size time-slices • TSON-flexible: statistical time division multiplexing of a wavelength with flexible size time-slices • Different OBS-related signal types can be defined for different OBS transport planes

  12. OBS Switching Capability and Encoding Type • A new Switching Type and a new LSP Encoding for MAINS • Optical Burst Switching Capability(OBSC, suggested value: 140) • indicates the switching preformed on a link, which supports the time-shared use of a wavelength. • groups all the specific implementations of optical burst switching • TSON LSP Encoding Type (suggested value: 240) • refers to the TSON specific modelling of the time-shared use of a wavelength (i.e. statistical time division multiplexing and hierarchical resource structure)

  13. Sub-wavelength LSP signalling • OPST and TSON regions are managed by a single MAINS GMPLS CP instance (i.e. OPST/TSON interconnections are I-NNI interfaces) • GMPLS extensions for Multi Region Networks (MRN) to cope with the different switching capabilities offered by the OPST and TSON regions • MAINS GMPLS CP supports the hierarchical LSP creation procedures specified in draft-zhang-ccamp-gmpls-h-lsp-mln, built on top of the standard IETF LSP hierarchy procedures • Full Path Computation at source node • Single Inter-layer Path Computation

  14. Sub-wavelength routing • The MAINS GMPLS CP disseminates routing information about network resources availabilities inside the metro domain supporting the IETF GMPLS routing architecture • MAINS metro network domain is modelled as a single Routing Control Domain (RCD) • a single IGP routing area is configured in the whole metro domain

  15. MAINS GMPLS functional architecture

  16. MAINS Path Computation • The MAINS path computation is compliant with the IETF PCE architectural model and supports both the centralized and distributed model • The MAINS path computation also implements mechanisms and procedures to cope with the Multi-Region traffic engineering issues, and supports the IETF inter-layer path computation procedures (RFC5623) • Single PCE path computation

  17. Interworking with standard PCEs • The centralized PCE server can be interfaced with standard PCEs in neighbouring domains to support PCE-based multi-domain path computation procedures at the MAINS E-NNI • MAINS supports the hierarchical PCE model

  18. GMPLS protocols extensions • OSPF-TE protocol extensions • Aggregated sub-wavelength resources availabilities advertisement • Advance reservations • RSVP-TE protocol extensions • Sub-wavelength traffic profiling • Sub-wavelength label format • Advance reservations • The new OSPF-TE and RSVP-TE objects and capabilities defined in MAINS are intended to be optional additions to the protocol messages and procedures defined for standard GMPLS

  19. OSPF-TE extensions: sub-wavelength resources advertisement [1] • MAINS defines a new sub-TLV for the TE LSA TE-link top-level TLV • the Sub-wavelength availability sub-TLV (Type=32768) • Wavelength Id: 32-bit unique identifier of the wavelength (“Wavelength Label” IETF Otani format) • Just one sub-TLV type is defined for Sub-wavelength availability sub-TLV: • the Calendar event sub-TLV (Type=1) • Timestamp: 64-bit timestamp compliant with IETF NTP format. • Signal Type: indicates the specific sub-wavelength signal type • TSON-1 signal (value=1): 10µs fixed size slots.

  20. OSPF-TE extensions: sub-wavelength resources advertisement [2] • The Sub-wavelength availability sub-TLV (along with its Calendar event sub-TLVs) is intended to be used in support of the Available Labels sub-TLV specified by IETF for WSON support in OSPF • Base Label: 32-bit unique identifier of the WSON base wavelength • Bitmap: each bit represents a wavelength: a value of “1” indicates the wavelength is fully available (i.e. all the slots are free), “0” otherwise. • The Sub-wavelength availability sub-TLV is not advertised for those wavelengths which are set as free in the Available Labels sub-TLV bitmask, since they have all the slots unallocated

  21. RSVP-TE extensions: sub-wavelength label • A new object is defined in the LABEL class (Class-Num = 16) to identify the sub-wavelength resources to be reserved in the transport plane for a certain network service • Sub-wavelength LABEL object (C-Type=TBD) • Slot-to-bit mask: identify the position in the frame of the slots to be reserved for the specified wavelength. Positions marked with “1” in the bit-mask identify the slots to be allocated, “0” otherwise • The Sub-wavelength LABEL object is used in • EXPLICIT_ROUTE object (Class-Num=20, C-Type=1) • SUGGESTED LABEL object (Class-Num=129)

  22. MAINS extensions to OIF-UNI: endpoint identification • Each MAINS edge resource is identified by a standard TNA address plus a list of 60-bit Ethernet labels • just one of the 60-bit configured Ethernet labels (for each edge resource) must be signalled at the MAINS UNI • A new Source and Destination TNA Address sub-type is defined in MAINS to specify the 60-bit Ethernet label • The GENERALIZED_UNI Object, included in each RSVP Path message at the MAINS UNI, will contain: • Two Source/Destination TNA Address sub-objects: • an IPv4/IPv6/NSAP globally unique address to identify the source/destination edge data-link • a 60-bit Ethernet label

  23. MAINS Control Plane implementation activities [1] D3.2: Implementation of service-network interface [planned@M19] Client-side Call signalling functionalities CCC-a/CCC-z in the MNSI Gateway MAINS UNI client-side signalling functionalities RSVP-TE extensions @ MAINS UNI-C MNSI Gateway MAINS LER (edge) MAINS Network Service Controller (client-part) [CCC-a/CCC-z] MAINS Network Service Controller (network-part) MNSI Agent (provider) MAINS UNI-C MAINS UNI-N Res Ctrl Agent MAINS GMPLS signalling (RSVP-TE) Server Client MNSI MAINS UNI

  24. MAINS Control Plane implementation activities [2] D3.4: Implementation of GMPLS extensions [planned @M24]

  25. MAINS Architecture • We must transfer large VM images (~60 GB) from/to nodes on the edge of the network to keep service latency at a minimum. • Network has NO congestion. • To maximize efficiency of link usage we must avoid small packets.

  26. MAINS Optical Network (OBST/TSWON) • TSWON (U. of Essex, UK): Tunable Sub-Wavelength Optical Network • to deliver highly flexible statistically-multiplexed optical network infrastructure guaranteeing contention-free packet/circuit services. Both a time-shared utilization of optical resources (ie. wavelengths) and a two-dimensional tunability (frequency-domain and timedomain) across all the ingress nodes of the optical network.

  27. OBST/TWSON vs TCP • The optical network has no congestion loss. TCP provides a bunch of mechanisms to avoid it (slow-start, throttling, SACKs,…) but they don’t apply to this scenario. Losses due to contention shouldn’t cause throttling. • TCP/IP ACK’s which are not piggy-backing are precisely that: small packets. Not adequate for underlying fabric. ACK’s don’t piggy back on file transfers. • Small ACK packages could consume time-slices in the OBST network, hurting performance. • Standard TCP doesn’t perform too well in LFN (high bandwidth-delay product) anyways.

  28. Selective Repeat ARQ • Advantages: • Fairly sequential memory-HD access, this always yields slightly better performance (a lot better in the case of HD’s). • Always attempting to make full use of link capacity. • Great percentage of packets sent at MTU size (>99.9% for 10 MB files and larger) so we maximize OBST/TSWON time slice utilization. • Simpler implementation. • Disadvantages: • Application specific. • Decreased flow rate/packet drop control.

  29. Results • 2 x Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz • 6GB RAM • 2 x 10GE (Intel 82598) NICs • Jumbo Frame MTU: 9K • Test file: 2GB iso • Rates Achieved: • TCP: 7.4 Gbps • MAINSTP Go-Back-N: 3.2 Gbps • MAINSTP Selective Repeat ARQ: 8.5 Gbps • Current results would allow to transmit a 60GB iso in ~61 secs. • Acceptable boot-up time?

  30. Results

More Related