ASON/GMPLS network evolution: the NOBEL project … | C. Cavazzoni, A. D’Alessandro, ASON/GMPLS...

GRUPPO TELECOM ITALIA

Politecnico di Torino, 15 January 2008

| C. Cavazzoni, A. D’Alessandro, A. Di Giglio, G. Ferraris, R. Morro|

0

ASON/GMPLS network evolution: the NOBEL project visionThis seminar is based on results of the NOBEL phase 2 project, funded by the European Commission in the 6th Framework Programme

1

| C. Cavazzoni, A. D’Alessandro, A. Di Giglio, G. Ferraris, R. MorroASON/GMPLS network evolution: the NOBEL project vision


OutlineEvolution of core networks: the “IP over Optics” concept

Driver for the evolution of backbone networks

The “delayering” concept

The “IP over Optics” architecture

Next generation optical networks based on ASON/GMPLS control plane

Requirements for the evolution of Optical Networks

The Optical control Plane

The Peer-to-peer and the Overlay models

Functions and interfaces

An example of “Bandwidth on Demand” service

Signaling protocols

Standardization and research activities

OIF interoperability demonstrations

The NOBEL phase 2 project

The MUPBED project




2

Evolution of core networks: the “IP over Optics” concept

3



Summary

Driver for the evolution of backbone networks

The “delayering” concept

The “IP over Optics” architecture


4



The old telecommunications market

TLC market dominated by traditional voice services (POTS) and low rate leased lines

Low level of competition

Low bandwidth requirements

Simple traffic forecasts

High revenues


5



The new telecommunications market

Fast growth of broadband services (fast internet access, contentdistribution, ...)

Higher level of competition

High bandwidth requirements

Difficult traffic forecasts

Lower revenues for new services


6



Traffic evolution on the backbone

2001200019991998

Voice

Data

50

100

150

200

250Total traffic(normalized values)

Source: Cisco


7



The role of IP

Internet Protocol was created for the transport of data between computers

Due to the broad diffusion of Internet it is now available on any computer directly integrated in the Operating System

It is now considered the protocol for the integration of different services on a single network infrastructure (Internet access, VoIP, IPTV, ...)


8



Fast traffic growth

Use of IP as the protocol for the integration of different services on the same transport network

Difficulty in traffic forecasts

Reduction of operator revenues due to competition and new business models

Large amounts of bandwidth at a low cost

New services to differentiate from competitors

New networks with improved scalability and flexibility

Market trends and operator needs


9



Evolution of Network Layering

SDH

ATM

IP

1998

WDM

SDH

IP + MPLS

2004

SDH / WDM

IP + MPLS

2006

SDH

ATM/FR

1996

WDM

SDH

ATM

IP

2000

Delayering


SDH / OTN

IP + MPLS

2008

10



The “IP over optics” architecture

IP/MPLS Layer

Optical/SDHLayer

Physical links(WDM line systems)

Logical links

LSR(Label Switch Router)

ODXC(Optical/Digital Cross Connect)





11


12



Summary

Requirements for the evolution of Optical Networks

The Optical control Plane

The Peer-to-peer and the Overlay models

Functions and interfaces

An example of “Bandwidth on Demand” service

Signaling protocols


13



Fast traffic growth

Use of IP as the protocol for the integration of different services on the same transport network

Difficulty in traffic forecasts

Reduction of operator revenues due to competition and new business models

Large amounts of bandwidth at a low cost

New services to differentiate from competitors

New networks with improved scalability and flexibility

Market trends and operator needs


14



New requirements for the Optical Layer

Network scalability and flexibility

Transparent transport of different client signals (SDH, ATM, IP, …) but optimised transport of IP

Fast and automatic end-to-end provisioning of optical channels

Fast and efficient rerouting of connections in case of failure

Dynamic set-up of new connections based on a client/customer request It enables Bandwidth On Demand services


15



Meshed architecture preferred for its flexibility and scalability

Fast automatic routing and rerouting requires a certain level of “intelligence” in the optical network Intelligent network vs. stupid network

Signalling between the nodes of the optical network (NNI) for coordinating different actions

Signalling between the client equipment (for example routers) and the optical network for connection set-up requests (UNI)

Re-use of protocols derived from the “IP-MPLS world” to cut development costs and to simplify interworking between layers

Intelligent Optical Networks based on ASON/GMPLS control plane

Impact on network architectures


16



The Optical Control Plane

Control plane(distributed intelligence)

Control plane(distributed intelligence)

X

ManagementSystem

Bandwidthrequest or release fromclients

Network failureMain Control Plane functions• Automatic Topology discovery (Plug-and-play operation) • Automatic Routing• Signaling for automatic set-up e tear-down of connections


17



The MPLS concept:separation of routing and forwarding

Edge LSR

LSR LSR

LSR

LSRLSR

Edge LSR

Edge LSR

MPLS Network

LSP

31

24 85

11

LSP Label Switched PathLSR Label Switch RouterMPLS Multi Protocol Label Switching


18



Application of MPLS concept toOptical Networks

Optical network

OXC

OXC OXC OXC

OXC

OXCOXC

OXC

LabelSwitchedPath

LambdaSwitchedPath

Edge OXC

Mapping of Label Switched Pathon wavelength(Lambda Switched Path)


19



GMPLS control planeLabel Switching Routers (LSR) with different types of interfaces

Packet Switch Capable (PSC)

Layer-2 Switch Capable (L2SC)

TimeDivision Multiplexing Switch Cap. (TDM)

Lambda Switch Capable (LSC)

Fiber Switch Capable (FSC)

MPLSMPLSGMPLSGMPLS

Clear distinction between control plane and forwarding plane

Extension and/or modification of existing and well known signaling (RSVP-TE) and routing (OSPF, IS-IS) protocols

Introduction of a new protocol (LMP, Link Management Protocol) for link control between adjacent nodes, fault detection and localization


20



LSP hierarchyLSP1 LSP2 LSP3 LSP4 LSP5

Fibre network: FSC interfaces

IP network: PSC interfaces

SDH network: TDM interfaces

WDM network: LSC interfaces

Layer-2 network: L2C interfaces


21



Peer-to-peer model

No Distinction Between UNI, NNI

Routers control end-to-end path selection

Significant amount of state and control information flows between the IP and optical layer

OXC

Optical Network

OXCOXC

OXC OXC

OXC OXCOXC

OXC

OXC


22



Overlay model

Client server approach between optical layer and edge network elements

Optical User Network Interface (UNI) exports the service interfaces

Routing information may or may not be exchanged

Optical Network

OXCOXC

OXC

OXCOXC

OXC

OXC


23



ONE A ONE CONE B

CP A CP B CP C

Transport plane

Control plane

Management plane

UNI data

E-NNI control

NMS

Router Client A Router Client B

UNI: User to Network InterfaceI-NNI: Internal Network to Network InterfaceE-NNI: External Network to Network Interface NMI-A: Network Management Interface for the ASON Control PlaneNMI-T: Network Management Interface for the Transport Network

ASON architecture and interfaces

CCI CCI CCI

NMI-A NMI-T

E-NNI data

UNI control

UNI data

UNI control

I-NNI control

I-NNI data

CCI: Connection Control InterfaceONE: Optical Network ElementCP: Control PlaneNMS: Network Management System


24



ASON connection types

ManagementPlane

Permanent Connection

Provisioning RequestsControlPlane

Soft-Permanent Connection

Connection Request

NNI NNI

Set-up Requests

ManagementPlane

ControlPlane

Switched Connection

Connection Request

UNI

NNI NNI

Set-up Requests

Connection Request

UNI


25



UNI User to Network InterfaceE-NNI External Network Node InterfaceI-NNI Internal Network Node InterfaceONE Optical Network Element

Source: OIF

Signaling Interfaces


AdministrativeDomain

AdministrativeDomain

UNI

E-NNI

I-NNI

UNI

Client

Client

ONE

26



Today, in the transport network…

Node C

Node A

Transport network

Node B

A-B bandwidthis not sufficient

…when traffic grows…We need more

bandwidth

27



Node C

Node A

Transport network

Node B

…the customer contacts the provider...

A customer’s request…

FAX:Connect portsAn and Bm...

28



…the job order moves on...

Node A

Transport network

Node B

JOB ORDER:Connects portsAn and Bm...

Node C

29



Node A

Transport network

Node B

Which route?…the operator looks for a route...

Node A

Node B

Node C

30



Node A

…a route is found...…the network is re-configured

Node B

Node C

31



There is a signallingbetween network elements

In an “intelligent” transport network…

Each element knows the status of the whole network

32



Node C

Node A

Transport network

Node B

…when traffic grows…

A-B bandwidthis not sufficient

More bandwidth is required

33



Connection setup request (A,2,B,4,...)

Node A

Transport network

Node B

…a new connection with more capacity is requested…

Node C

34



The contacted network element finds a route to the destination...

Node A Node B

Connection setup request (W,i,X,j,Y,k,Z,l,...)

…the connection setup procedure is activated…

…and sends the connection setup request Node C

35



The resource availability is confirmed

Node A Node B

Setup acknowledgment (W,i,X,j,Y,k,Z,l,...)

…the requested connection is created

…all the equipment are configured and the connection is setup Node C

36



Intelligent Transport Networks are based on...A distributed Control Plane

Signalingprotocols for

dynamic setup and teardown of connections

Discoveryprotocols for

automatic serviceand neighbour

awarenessRouting protocols

for automaticrouting

Extensions of protocols already in use in IP/MPLS networks(RSVP-TE, OSPF-TE) + a new protocol (LMP)


37



Labels and control channel in GMPLS networks

In a MPLS network the label is only an identifier (an header attached to an IP packet or a field in a frame/cell)

In a GMPLS network the label can be associated to a physical entity (time slot, wavelenght, fibre)

In a MPLS network the control channel used to connect the control plane of the different equipment (routing, label distribution etc.) is the same used by the transport plane

In a GMPLS network the control channel can be different from the transport plane


38



Link BundlingIn a MPLS network each node keeps in the "link state database" the information about all the adjacent nodes and the link connected to them, that are needed for the routing protocols

Typically, a pair of adjacent nodes are connected by only one link

In a GMPLS network the number of links between two adjacent nodes can be very high

the link state database becomes very large

problems with the management of the database

problems with the scalability of routing protocols

The parallel links between a pair of adjacent nodes are grouped in a single abstract entity, called “bundled link”

The link state database includes only information about the bundled links because the routing protocols do not need information about all the parallel physical links


39



Unnumbered link

In a MPLS network an IP address is assigned to each LSR port

The high number of link in a GMPLS network introduces the following problems

High number of IP addresses needed (especially if IPv4 is used)

Complexity in the address management and node configuration

The concept of "unnumbered link" is introduced

Each node is identified by a parameter called “router ID”

All the link connected to a given node are identified by a localparameter called “link number”

Each link in the network is identified by the pair<router ID, link number>


40



Basics of IP RoutingIP routing protocol

Exchange of information between IP routers that allow them to determine how to forward IP packets

There are different types of routing protocols

Distance Vector (RIP, IGRP)

Path Vector (BGP)

Link State (OSPF, IS-IS)

Link State Routing protocols in particular support distribution of network topology as links and nodes

For IP, every router must have exactly the same network topologyinformation (links, nodes, and link wts.)

Every router must run exactly the same path computation algorithm

Failure to insure these last two requirements can result in routing loops and “black holes”

41



Data Plane in Transport Networks and classic IP Networks differ

For classic IP, every packet is forwarded based on address translation

For label switching (generalized to TDM or WDM), once a cross connection is made, data flows without needing further path computation

ASON Routing IP Routing and Transport Network Routing

Control Plane

L1 Bearer Topology

G.7715 CompliantProtocol

Cross Connec

tSDH Path

Data Plane

Peer Routing Controllers

Source Route Algorithm

Signaling

SDH Path

TopologyDatabase

OSPF

Control Plane

Data Plane

IP router Peers

Shortest Path Algorithm (Dijkstra)

LSA

Header

IP

IPForwarding

IP ForwardingTable

IP address Next Hop

Transport Routing and Forwarding

IP Routing and Forwarding

Control Plane

L1 Bearer Topology


Cross Connec

tSDH Path

Data Plane



Signaling

SDH Path

Control Plane

L1 Bearer Topology


Cross Connect

SDH Path

Data Plane



Signaling

SDH Path

TopologyDatabase

OSPF

Control Plane

Data Plane

IP router Peers


LSA

Header

IP

Header

IP

IPForwarding

IP ForwardingTable

IP ForwardingTable

IP address Next Hop



Control Plane

L1 Bearer Topology


Cross Connec

tSDH Path

Data Plane



Signaling

SDH Path

Control Plane

L1 Bearer Topology


Cross Connec

tSDH Path

Data Plane



Signaling

SDH Path

TopologyDatabase

OSPF

Control Plane

Data Plane

IP router Peers


LSA

Header

IP

Header

IP

IPForwarding

IP ForwardingTable

IP ForwardingTable

IP address Next Hop



Control Plane

L1 Bearer Topology


Cross Connec

tSDH Path

Data Plane



Signaling

SDH Path

Control Plane

L1 Bearer Topology


Cross Connect

SDH Path

Data Plane



Signaling

SDH Path

TopologyDatabase

OSPF

Control Plane

Data Plane

IP router Peers


LSA

Header

IP

Header

IP

IPForwarding

IP ForwardingTable

IP ForwardingTable

IP address Next Hop



42



ASON RoutingSome differences between IP and Transport Network Routing

Prevented by strict source routingPotential problem any time

the routing table changes

Looping

Data can be forwarded on

existing connections but new connections cannot be created

Data cannot be forwarded

without stable routing database

Forwarding dependency

Path computed only at connection

setup, usually only at the source

Path computed for each packet

at each node

Forwarding process

May be different path computation

algorithms at different nodes

Identical path computation

algorithm at each node

Path computation

Domain-specific: may be distributed

or centralized

Always distributedDistribution of Routing

Protocol Entities

Transport RoutingClassic IP Routing

43



The Link Management Protocol

A new protocol is needed to manage all the new aspects related to adjacent nodes specific of GMPLS networks: the Link Management Protocol (LMP)

Main LMP functions

management of the control channel

check of the status of the physical links (fault management)

correlation between parallel physical links and the corresponding bundled links


44



ASON/GMPLS signaling – an example


UNI UNI




45

Standardization and researchactivities

ASON/GMPLS network evolution: the NOBEL project vision – Part 2

46



Summary



The MUPBED project


47



About the OIFMission: To foster the development and deployment of interoperable products and services for data switching and routing using optical networking technologies

The OIF is the only industry group that brings together professionals from the data and optical worlds

80+ member companies representing the entire industry ecosystem:Carriers and network users

Component and systems vendors

Testing and software companies

48



Goal - Evolution towards convergence of requirements & protocols

1999/2000 MPLS: flat “peer” model, data/signaling congruent, IP only, data behavior (e.g., connection tear-down w/o request)

2001: Carrier requirements across IETF, OIF, and ITU-T re need for support of commercial business & operational practices

2003: Evolution of GMPLS signaling protocol, used as normative base for ASON extensions

2004-2006: Ongoing communications among all three SDOs on requirements and protocol work

IETF GMPLS Umbrella

--

ITU-T ASON Umbrella

OIFImplementation

Agreements

OIFImplementation

AgreementsIETF GMPLS Umbrella

--

ITU-T ASON Umbrella

OIFImplementation

Agreements

OIFImplementation

Agreements

OIFImplementation

Agreements

OIFImplementation

Agreements

Standards Development Organizations (SDO) Interaction

49



StandardsSpecifications

Interoperability Tests & demonstrations

OIF

Carrier sites

Field trials

Deployment

OIFITU-TIETF

Feedback

OIF performs / organizes the next major step towards implementation interoperability evaluations of prototype implementations:•Prove of concept•Feedback to standardization•Fosters follow up activities

OIF supports close relation of standardization and R&D and early implementations

Interoperability Demos Role in Standards to Deployment

50



Interoperability DemonstrationsObjectives / Goals

OIF PerspectiveMember evaluation, validation, proof of concept of current OIF draft specifications & IA for interoperable network solutionsFeedback assessment from multi-vendor testing environment to standardization/specification work

Carrier PerspectiveEarly adoption, evaluation, of interoperability testing results demonstrated in multi-vendor environment.Feedback to vendor community on early implementations and integrations based on practical experiences and lessons learned

Industry PerspectiveShowcase OIF contributions, build market awareness of emerging technologies, services and networking solutions.Public forums (Optical conference & exhibitions) utilized

51



OIF Implementation Agreements and Interoperability Demos

OIF Implementation Agreements

UNI 1.0 signalingUNI 1.0r2 signalingE-NNI 1.0 signaling E-NNI 1.0 routing

UNI 2.0 signalingE-NNI 2.0 signaling

2001 2002 2003 2004 2005 2006 2007

OIF Networking Interoperability Demonstrations

Lab Location

Trade Show

New Capabilities

Tested

UNH

SuperComm

Draft UNI 1.0

UNH

OFC

Draft E-NNI signaling and routing

Global – 7 carriers

SuperComm

CP-enabled SONET/ SDH data plane

Ethernet over SONET/SDH data plane-only test (GFP/VCAT/LCAS)


SuperComm

Draft extensions for control plane-enabled EPL

Data plane-only test of EVPL and ELAN


ECOC

Pre-IA UNI 2.0 and E-NNI 2.0 signaling

Control plane failure recovery

BW modificationControl plane neighbor

discovery

52



C-11VC-11TU-11Aligning

Mapping

× 1× 1

× 3

× 3× 1

× 1

× 3

× 4

× 7× 7

STM-1 AUG-1 AU-4 VC-4

AU-3 VC-3

C-4

C-3

C-2

C-12

VC-3

VC-2

VC-12

TU-3

TU-2

TU-12

TUG-2

TUG-3

AU-4 Pointer processing

Multiplexing

× 4

× 1× 1STM-16 AUG-16 VC-4-16c

VC-4-4c

×1

× 4

STM-64 AUG-64

× 1× 1

× 4

STM-4C-4-4c

C-4-16c

× 1STM-0

× 1× 1STM-256 VC-4-256c C-4-256c

× 1VC-4-64c C-4-64c

AU-4-256c

AU-4-64c

AU-4-16c

AU-4-4c

AUG-256

AUG-4

× 4

Synchronous Digital Hierarchy (SDH) multiplexing structure

53



GFP Mapping to SONET/SDH –Rec. G.7041

Virtual Concatenation –G.707, G.783, G798

Independent connections -ASON compliant OIF UNI/ENNI

VC-3

VC-3100 Mbit/s Ethernet PHY 100 Mbit/s

100Mbit/s MAC service – Rec.

G.8011LCAS signalling to add to

Virtual Concatenation Group – Rec. G.7042

Ethernet transport over SDH (GFP + VCat + LCAS)

GFP: Generic Framing Procedure VCat: Virtual ConcatenationLCAS: Link Capacity Adjustment Scheme

54



Generic Framing Procedure (GFP)

55



Ethernet frame transport

G.7041/Y.1303_F7-1

Ethernet MAC frame GFP frameOctets

PLIcHECType

Preamble tHECStart of frame delimiter GFP extension hdr

Destination Address (DA)Source Address (SA)

Length/TypeMAC client data

PadFrame Check Sequence (FCS)

Bits1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

71662

4

2222

0-60

GFPpayload

Octets

Bits

56



Virtual Concatenation (VCat)Allows the creation of circuits with bandwidth multiple of VC12, VC3 e VC4 (N* 2Mbit/s, N* 34 Mbit/s, N* 155 Mbit/s)

Circuit bit rate is not limited by the line rate (STM-N)

Defined in ITU-T G.707 Recommendation

PayloadOH

Client

PayloadOH

PayloadOH

PayloadOH

VC n.1VC n.2

VC n.3

987654321

Client byte

Mux/Demux

VC n.1 VC n.2 VC n.3

369

147

258

Buffer

57



Link Capacity Adjustment Scheme (LCAS)

LCAS allows a dynamic modification of the bandwidth allocated through VCat by adding or deleting members to the Virtual Concatenation Group (VCG)

Bandwidth modification can be triggered by the management system, by the control plane or by a network failure

The two terminations are coordinated in order to modify the capacity without service interruption

ITU-T G.7042 “Link capacity adjustment scheme (LCAS) for virtual concatenated signals”

SDH (VC4)

VC -4 trail (150 Mbit/s )

1

2

3

4

XX

4

3

2

1

C4-

VX

vpa

yloa

dLC

AS

VC-4-Xv trail (X* 150Mbit/s max, variable bandwidthVirtual Concatenation Group (VCG)

VariableBit rate

Ute

nte

Ute

nte

VC -4 trail (150 Mbit/s )

C4-

VX

vpa

yloa

dLC

AS

VariableBit rate

58



UNI 1.0 R2UNI 1.0 R2

E-NNI 1.0

SONET/SDH

SONET/SDH

SONET/SDH

SONET/SDH

SONET/SDH SONET/SDH

RouterRouter

OIF Interop 2004 Demonstration

Ethernet/SDH Metro

Ethernet/SDH Metro

IP/ASON Backbone

10 Mbit/s

Protection and recovery demonstration

Dynamic setup of backbone connection

Mapping of Fast Ethernetand Gigabit Ethernet

20 Mbit/s

59



Protection and recovery demonstration

60



OIF @ ECOC 2007


61



OIF 2007 Demo Technology and FeaturesEnd-to-end provisioning of dynamic switched Ethernet services

Over multiple, control plane-enabled intelligent optical core networks

Using OIF UNI 2.0 and OIF E-NNI IAs

Featuring:

Ethernet Private Line Service

Control Plane Neighbor Discovery

Non-Disruptive Bandwidth Modification

Control Plane Failure Recovery

62



Ethernet Services

The Metro Ethernet Forum (MEF) classifies Ethernet services as E-Line (point to point) and E-LAN (multipoint to multipoint). E-Line can be further divided into:

Ethernet Private Line (EPL), where an Ethernet port has dedicated bandwidth across a provider network (no service multiplexing)Ethernet Virtual Private Line (EVPL), where multiple Ethernet ports share bandwidth across a

provider network (service multiplexing)

OIF UNI 2.0 supports both EPL and EVPL servicesThe demonstration focuses on interoperable on-demand Ethernet Services, offered under the ITU-T Recommendation G.8011.1 EPL model.

Carrier CDomain

OIF UNI OIF E-NNI OIF UNI

Carrier ADomain

Carrier BDomain

OIF E-NNINE NE NE NE NE NE

EthernetClient

EthernetClient

Ethernet EthernetSONET/SDH

Ethernet Virtual Circuit (EVC)

63



OIF Multi-Layer Call Control

Actions are coordinated between call controllers at each layerVCAT treated as a separate layer, to allow control and sequencing of VCG membersTraffic parameters are tailored to each layer

These techniques can be applied to other layers besides Ethernet/VCAT/SONET-SDH

SONET/SDH Layer Call Control

Ethernet Layer Call ControlUNI-N UNI-N UNI-CUNI-C

VCAT Layer Call Control

Carrier CDomain


Carrier ADomain

Carrier BDomain


EthernetClient

EthernetClient


DEMO

64



Control Plane Neighbor Discovery

Discovery is a dynamic exchange of information for links brought into service – replacing manual configuration with automated “plug and play”

In-band overhead bytes (J0) describe local transport and control plane resources

Control plane entity correlates local and remote node information

In-band message formats (such as Layer Adjacency) have been defined in ITU-T.The OIF demo extended this capability with out-of-band messages for exchanging discovered information (a Layer Adjacency Discovery response message)

Discovery was also extended to exchange control plane information, such as identifiers of control plane and transport plane entities, and routing area information

Results of demo should assist future discovery standards development

Out-of-band messages

Out-of-band messages

In-band (J0)

message

In-band (J0)

message

Control Plane

Transport Plane

65



300 Mbit/s

Set up 300 Mbit/s connection

Non-Disruptive Bandwidth Modification

VCG Members A, B, C

450 Mbit/s

VCG Members A, B

Increase BWto 450 Mbit/s

Ethernet Layer

SONET/SDH Layer

UNI-N UNI-N UNI-CUNI-C

VCAT Layer

Carrier CDomain


Carrier ADomain

Carrier BDomain


EthernetClient

EthernetClient


Three VC-4 ConnectionsTwo VC-4 Connections

Bandwidth modification adjusts connection capacity to meet elastic demandEnables carrier to “right-size” client Ethernet BW using legacy SONET/SDH networkClients use/billed for only what they needNetwork utilization is optimized

66



Test scenario for SCN failure recovery

Hello

HelloHello

Hello

Control plane

Data plane

Hello

Hello Hello

Hello

67



Test scenario for control plane failure recovery

HelloHello

HelloHello

Control plane

Data plane

68




HelloHello

HelloHello

Control plane

Data plane

69



Status Status


HelloHello

HelloHello

Control plane

Data plane

70



71



Summary



The MUPBED project


72



The NOBEL phase 2 ProjectStarting date: 1 March 2006

Duration: 2 years

Consortium: 32 partnersOperators: BT, Deutsche Telekom, France Telecom, Telecom Italia, Telefonica, Telenor

Vendors: Alcatel (3), Cisco, Coreoptics, Ericsson (2), Lucent Technologies (2), Pirelli Labs, Siemens

Universities and Research Centers: ACREO, AGH, BME, Corecom, CTTC, Fraunhofer-HHI, IBBT, ICCS, INFN, Politecnico di Torino, Scuola Superiore S. Anna, UCL, University of Padova, University of Stuttgart, UPC


73



Main goal

Based on the results of the NOBEL project, the main goal of the Integrated Project NOBEL phase 2 is:

to carry out analysis, feasibility studies and experimental validations of innovative network solutions and technologies forflexible, scalable and reliable optical networks, thus enabling broadband services for all

To assess and demonstrate core and metro network architectures in terms of scalability and end-to-end interoperability through network emulations and experiments


74



GMPLS TDM

OIF TDM

GMPLS LSC

GMPLS LSC

OIF TDM

OIF TDM

MPLS PSC

GMPLS FSC

OIF TDM

NOBEL2 Test-bedsLocation, Inter-domain interfaces and Switching capability

75



NOBEL2 Physical Control Topology: NOBEL2 star-hubrouter

InternetInternet

AL10.65.0.0/16

CNAF10.69.0.0/16

DT10.131.0.0/16

TI10.134.0.0/16

TID10.67.0.0/16

UPC10.68.0.0/16

NOBEL2 star-hub(Linux-based Router @ CTTC)

CTTC10.64.0.0/16 10.64.254.128

10.65.0.2 10.69.250.1 10.131.17.100 10.134.21.10 10.67.0.69 10.68.0.2

A.B.26.244 C.D.98.20 E.F.67.14 G.H.2.40 I.J.93.157 K.L.32.231

M.N.62.100

IPSec Tunnels

Interconnectivity

Monitoring

Accounting

76



Dual-Function NOBEL2 ProxyMulti-Domain (ASON, GMPLS)

Detection of a connection request crossing different inter-domain interfaces between two connected testbeds:

Protocol Translation: OIF<-> GMPLS

Multi-Layer (LSC, TDM)

Detection of a connection request crossing different switching layer capability between two connected Testbeds

Switching Mapping: LSC <-> TDM

77



GMPLS PATH (LSC LSP)

GMPLS RESV (LSC LSP)

OIF UNI 1.0 R2 PATH (TDM LSP)

OIF E-NNI 1.0 PATH (TDM LSP)

UNI Session (TDM)

Proprietary Session

Proprietary Session

UNI Session (TDM)

E-NNI Session (TDM)

E-NNI Session (TDM)

GMPLS Session

(LSC)


OIF UNI 1.0 R2 RESV (TDM LSP)


OIF E-NNI 1.0 PATH (TDM LSP)

OIF E-NNI X.0 RESV (LSC LSP)OIF E-NNI 1.0

RESV (TDM LSP)

ASONTDM

ASONTDM

ASON NETWORK

ASONTDM

ASONTDM

ASON UNI (TDM)

ASON NETWORKUNI UNIE-NNIE-NNI GMPLS NETWORK

ASON UNI (TDM)

GMPLS (LSC)

ASON E-NNI (TDM)

ASON E-NNI (TDM)

GMPLS (LSC)

GMPLSLSC

GMPLSLSC

GMPLS RESV (LSC LSP)

End of ASON Domain and TDM Switching Layer -> PATH Protocol Translation (OIF-> GMPLS) and Switching Mapping (TDM -> LSC)

End of ASON Domain and TDM Switching Layer -> PATH Protocol Translation (OIF-> GMPLS) and Switching Mapping (TDM -> LSC)

End of GMPLS Domain and LSC Switching Layer -> PATH Protocol Translation (GMPLS->OIF) and Switching Mapping (LSC -> TDM)

End of GMPLS Domain and LSC Switching Layer -> PATH Protocol Translation (GMPLS->OIF) and Switching Mapping (LSC -> TDM)

End of GMPLS Domain and LSC Switching Layer -> RESV Protocol Translation (GMPLS->OIF) and Switching Mapping (LSC -> TDM)

End of GMPLS Domain and LSC Switching Layer -> RESV Protocol Translation (GMPLS->OIF) and Switching Mapping (LSC -> TDM)

End of ASON Domain and TDM Switching Layer -> RESV Protocol Translation (OIF-> GMPLS) and Switching Mapping (TDM -> LSC)

End of ASON Domain and TDM Switching Layer -> RESV Protocol Translation (OIF-> GMPLS) and Switching Mapping (TDM -> LSC)

TNA_A TNA_F

ASON/GMPLS Signalling protocol Interworking for NOBEL2 proxy

78



ASONTDM

ASONTDM

ASON NETWORK

ASONTDM

ASONTDM

ASON NETWORKUNI

E-NNI DT-CTTCGMPLS NETWORK

GMPLS (LSC)

OIF E-NNI 1.0 (TDM) OIF E-NNI 1.0

(TDM)

GMPLS (LSC)

GMPLSLSC

GMPLSLSC

ASON/GMPLS Proxy

OIF UNI 1.0 R2 (TDM)

OIF UNI 1.0 R2 (TDM)

NOBEL2 Star-hub

E-NNI TID-DT

ALU ALU

OIF E-NNI 1.0 (TDM)

OIF E-NNI 1.0 (TDM)

E-NNI TID-CTTC

ASON/GMPLS Proxy

UNI

EMULATED CTTC RC

TID RC DT RC

CTTC – DT Routing Adjacency

TID – DT Routing Adjacency

TID– CTTC Routing Adjacency ERC ERC

ALUALU

NOBEL2 Interworking Scenario

79



Summary



The MUPBED project


80



For further information: [email protected]

81



References

82



OIF presentation and newsletterswww.oiforum.com

OIF Implementation Agreementshttp://www.oiforum.com/public/impagreements.html

OIF workshops on ASON/GMPLS implementations in test and carrier networks http://www.oiforum.com/public/meetOIW050806.htmlhttp://www.oiforum.com/public/meetOIW073106testbeds.htmlhttp://www.oiforum.com/public/meetOIW101606.html

OIF Documents

83



Common Control and Measurement Plane (ccamp) Working GroupInternet-Drafts and Request For Comments (RFC) available at

http://www.ietf.org/html.charters/ccamp-charter.html

IETF GMPLS Documents

84



ITU-T Recommendations Accessibility Information

Go to the publications link and choose download per URL:

http://www.itu.int/publications/EBookshop.html

There is an explicit button from the download publications page where you can register up front for 3 free Recommendations

85



Some Key ITU-T ASON RecommendationsFundamental (Protocol-Neutral) Architecture & Requirements

G.8080, Architecture for the automatically switched optical network (ASON), 2006 Revision – to be published imminentlyG.7713, Distributed call and connection management (DCM), 2006 Revision, to be published imminently G.7718, Framework for ASON Management, February ’05G.7714, Generalized automatic discovery for transport entities, August ’05 revisionITU-T G.7715/Y.1706 - Architecture and Requirements for Routing in the Automatic Switched Optical Networks, July 2002ITU-T G.7715.1/Y.1706 - ASON Routing Architecture and requirements for Link State Protocols, Feb. ’04ITU-T G.7712/Y.1703 - Architecture and specification of data communication network*, March ’03ITU-T T G.7716 - Control Plane Initialization, Reconfiguration, and Recovery, target Consent Nov. ‘06

86



Textbooks covering ITU-T Architecture Aspects (e.g., Functional Modeling, ASON)

Broadband Networking: ATM, SDH, and SONET; Michael Sexton and Andrew Reid; ISBN 0-89006-578-0 (see in particular Chapters 2 – 4)

http://www.amazon.com/gp/product/0890065780/ref=sib_rdr_dp/103-2003697-9480609?%5Fencoding=UTF8&me=ATVPDKIKX0DER&no=283155&st=books&n=283155

Achieving Global Information Networking; Varma and Stephant et al; ISBN: 0890069999 (see in particular Chapters 1-4)

http://www.amazon.com/gp/product/0890069999/ref=dp_return_1/103-2003697-9480609?%5Fencoding=UTF8&n=283155&s=books

SDH/SONET Explained in Functional Models : Modeling the Optical Transport Network; Huub van Helvoort; ISBN 0-470-09123-1

http://www.amazon.com/gp/product/0470091231/ref=sib_rdr_dp/103-2003697-9480609?%5Fencoding=UTF8&me=ATVPDKIKX0DER&no=283155&st=books&n=283155

Optical Networking Standards : A Comprehensive Guide for Professionals ; KhurramKazi; ISBN: 0387240624 (to be published June 2006; see – for example - Chapters 2, 16)

http://www.amazon.com/gp/product/0387240624/qid=1147161139/sr=1-1/ref=sr_1_1/103-2003697-9480609?s=books&v=glance&n=283155

87



Some Key ITU-T Functional Modeling Rec.Fundamental Architecture & Equipment

ITU-T Rec. G.803, Architecture of transport networks based on the synchronous digital hierarchy (SDH), March 2003ITU-T Rec. G.805 - Generic functional architecture of transport networks, March 2000ITU-T Rec. G.809 - Functional architecture of connectionless layer networks, March 2003ITU-T Rec. G.872, Architecture of optical transport networks, November 2001ITU-T Rec. G.8010, Architecture of Ethernet Layer Networks, February 2004ITU-T Rec. G.8110, MPLS layer network architecture, January 2005ITU-T G.8110.1, Architecture of Transport MPLS (T-MPLS) Layer Network, publication imminentITU-T G.783, Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks, March 2006ITU-T G.8021, Characteristics of Ethernet transport network equipment functional blocks, G.8121, Characteristics of Transport MPLS (T-MPLS) Equipment Functional Blocks, publication imminentEtc.

ASON/GMPLS network evolution: the NOBEL project … | C. Cavazzoni, A. D’Alessandro, ASON/GMPLS...

Documents

Transcript of ASON/GMPLS network evolution: the NOBEL project … | C. Cavazzoni, A. D’Alessandro, ASON/GMPLS...