Optical Nasir

7/31/2019 Optical Nasir

1/66

Nasir Ghani, Ph.D. , Industry Program Chair, OPTICOMM 2000, Dallas, TX, October 2000

IP Over OpticalIP Over Optical

Nasir GhaniNasir Ghani, Ph.D., Ph.D.

Industry Program Chair, OPTICOMM 2000Industry Program Chair, OPTICOMM 2000

[email protected]@sorrentonet.com

[email protected]@yahoo.com

Tutorial presented at OPTICOMM 2000, Dallas, TX, October 2000Tutorial presented at OPTICOMM 2000, Dallas, TX, October 2000


2/66


OutlineOutline

z Introduction

z Traditional Approaches

z Network Models

z Multi-Protocol Lambda Switching

z Lightpath Channel Routing

z Service Survivability

z Performance Monitoring

z Traffic Engineering

z Future Evolutions

z Conclusions

z References


3/66


IntroductionIntroduction

z Largescale commercialization of optical technology Wavelength division multiplexing(WDM) enabling technologies

Fibers (SMF up to 600 km, dispersion optimization for more)

Lasers (2.5 Gb/s, 10 Gb/s, tunability emerging)

Amplifiers with improved gains, advanced power equalization

Filters with narrower spacing, wider ranges, emerging tunability

Increasing density of channel counts (C and L bands)

Dynamic switching technologies (MEMS, bubble)

z Extension of WDM to a networking-level paradigm

Improving, re-configurable optical network elements

Add-drop multiplexers(O-ADM), cross-connects(WRS/OXC)

Many advanced networkingapplications emerging

Optical building blocks exist, the focus now is on developingintelligence to interwork with other (IP) devices


4/66



z Data traffic profiles are changing paradigms Explosion and increasing domination of IP traffic profiles:

Doubling times in months, outpacing electronic speeds

Over 80% of IP traffic is very delay insensitive, burstyE.g., email, web, ftp transfers (high peak-to-mean ratios)

Highly asymmetric profiles, variations (time-of-day effects)I.e., need for dynamic resource re-configurability

z Data network hierarchy undergoing a de-layering

IP emerging as the new convergence layerI.e., remove intermediate layers (ATM, SONET)

Data-centric paradigms are requiredI.e., multi-path routing, signaling, traffic engineering

More economic operations/maintenance costs

Effects felt everywhere: access, metro, core

Standardization work (IETF, OIF, ODSI, ITU-T)


5/66



Physical Optics Layer

High-Level Overview of Network Integration Models

WDM Layer

Layering (overlay)approaches

SONET

ATM

IP

IP

IP

Direct MPS-based approach

IPSONET

ATM

IP

IP

Traditional SONET-based approaches


6/66


OutlineOutline

zzz IntroductionIntroductionIntroduction

z Traditional Approaches

zzz Network ModelsNetwork ModelsNetwork Models

zzz MultiMultiMulti---Protocol Lambda SwitchingProtocol Lambda SwitchingProtocol Lambda Switching

zzz LightpathLightpathLightpathChannel RoutingChannel RoutingChannel Routing

zzz Service SurvivabilityService SurvivabilityService Survivability

zzz Performance MonitoringPerformance MonitoringPerformance Monitoring

zzz Traffic EngineeringTraffic EngineeringTraffic Engineering

zzz Future EvolutionsFuture EvolutionsFuture Evolutions

zzz ConclusionsConclusionsConclusions

zzz ReferencesReferencesReferences


7/66


Traditional ApproachesTraditional Approaches

z Largely based upon existing TDM (SONET) infrastructures Point-to-pointDWDM links interconnecting routers:

Multiple inter-router links (one per wavelength)

Rely on SONET control/provisioning (IP-ATM-SONET-DWDM)

Multiple layers to provide required service functions:

IP: application connectivity/routing, some traffic engineeringATM: traffic engineering (slow, mainly PVC based)SONET: transport and protection switchingWDM layer: pure transport capacity expansion

z Packet-Over-SONET (POS) is a well-known representation

IP packets framed in HDLC and mapped to SONET frames:Details of mapping in IETF RFC 1619

SONET provides transport and protection functionality

IP protocols for service provisioning, traffic control


8/66



IP-SONET-WDM via Packet Over SONET (POS)

Wavelength lasertransponders

DemuxMux

Widebandreceivers

Gigabit IP Router

IP routing protocols(OSPF, BGP)

IP/PPP/HDLC packetmappings to SONET frames(OC-48, OC-192)

Gigabit IP Router

SONET

SONET

Point-to-pointDWDM links(linear or ring

SONET topologies)


9/66



z Huge scalability concerns for large traffic volumes The glass-ceiling effect, limits of electronic processing:

E.g., IP or ATM buffering/classification/scheduling

Increased equipment costs, plant space requirements

Cannot keep pace with full, multi-wavelength line rates:

Cost, engineering challenges beyond OC-192 (10 Gb/s) Eachlayer must scale (lowest-common denominator effect)

Multiple (virtual) link adjacencies, routing protocol scalability

z Slow, inefficient service provisioning

SONET implies forklift capacity upgrades:

I.e., upgrade complete ring to increase capacity on single hop Complex multi-layer/box management (maintenance costs):

E.g., added ATM provisioning, AAL5 framing inefficiencies

Rigid service definitions restrict business modelsE.g., SONET all-or-nothing protection


10/66


OutlineOutline


zzz Traditional ApproachesTraditional ApproachesTraditional Approaches

z Network Models










11/66


z Move towards true optical (WDM) networking paradigms High-speed routers inter-connected by intelligent optical cores

Optical layer provides multi-layer capabilities on demand

Based on processing actions: (add, drop, switch, convert)

Enables scalability, extend lambdas across network hops:

I.e., uni-directional lightpathentities Data-control separation: inband (OSC,SONET),external (LAN)

z Many higher-layer networking applications

Improved, flexible connectivity: lightpaths virtual links

Multi-protocol/service: transparency for IP, ATM, GbE, etc.

Reduced layering: less equipment/maintenance costs

Improved survivability: obviates need for rigid TDM overlays

Traffic engineering: improved (IP,optical) utilization

Layering (overlay) and peer model concepts

Network ModelsNetwork Models


12/66


z Overall features First step in integration of WDM as network layer technology

Client-server model, separation of IP and optical domains:Client: IP routers, server: optical network

Conceptually similar to previous circuit-layer interworkings:

E.g., IP-over-ATM incarnations (such as MPOA) Optical network internals may/may not be proprietary:

E.g., Room for more generalized MPLS-based control

z Current developments

Staticand signaledoverlay versions:

First-generation WDM solutions based upon static approach Work on signaled optical user to network interface(UNI):

Interoperability possibly emerging in 2001?

Network Models: Overlay ModelNetwork Models: Overlay Model


13/66


Network Models: Static OverlayNetwork Models: Static Overlay

z Overall features Manually provision lightpaths, IP layer sees virtual links

NMS/EMS-based control, little standardization required:Controller computes lighpaths, commands nodes to setup

No protocol (UNI) exchange between IP and optical layers

Akin to ATM permanent virtual circuit(PVC) setup Also termed configuration or provisioned approach

z Shortcoming and concerns

Inflexible, slow, not suitable for large dynamic networks

Inability to adapt to rapid provisioning changes:

Automated higher-layer traffic engineering difficult Operator-assisted setup limits scalability, error-prone:

Resource control requires complex tools (training)

Advanced (signaled) protection switching concernsI.e., optical layer protocols are required


14/66


Network Models: Signaled OverlayNetwork Models: Signaled Overlay

z Optical user-to-network interface(UNI) model required Interface between optical network and clients (non-IP also):

Borderrouters and borderOXCs, in/out-band signaling

Service definitions to support multiple requirements:E.g., via lightpath channel attributes

Independent (likely proprietary) optical-domain protocols:Routing, topology discovery, signaling, survivability

Separate reachability mechanisms for IP address exchange:Pre-configured or dynamic (i.e., border client routers query)

O(N2) client mesh, O(N3) client route messaging (unscalable)

z

Basic UNI actions/operations Limited IP endpoint reachability information transfer:

Register/query client IP addresses, VPON identifiers, etc

Service discovery, explicit signaling functions:Request, release, query, and modify lightpaths


15/66


Physical Optical LayerModulation, transmission , amplification, wavelength routing/conversion, etc.

E.g., lasers, amplifiers, modulators, fibers

Optical LayerChannel routing, restoration/protection,

performance monitoringE.g., OXC/WRS, O-ADM nodes

IP (MPLS) LayerPacket/flow level QoS, routing/recovery and traffic engineering

E.g., IP routers, ATM/MPLS switches

Interface between IP andoptical layers is via a softwareUNI (dynamic provisioning)


Plane Hierarchies(Traditional signaled optical protocol layer)

Digital FramingPacket encapsulation, possibly w.overhead performance monitoring

E.g., SONET, digital wrappers, GbE

Control Plane Data Plane

IP-MPLS FramingPacket/cell encapsulation

E.g., MPLS shim header, ATM cell


16/66



z Lightpath channel attributes (i.e., service definition) Connection-related: Id, source/destination address (port),

user group (for scalability and security), duration

Physical: size, framing (e.g., SONET, digital wrappers, GbE),transparency, directionality, priority, delay

Routing/survivability: protection type (1+1, 1:1, M:N),diverse routing, recovery time, recovery type

Lightpath routing/policy control provisions (request) attributes

z Current status

Very strong interest standardizing a UNI definition:

Optical-clouds with common (opto-electronic) interfaces Many groups are developing models (OIF, ITU-T, ODSI)

Will a unifying interface standard emerge soon?


17/66



Architecture Overview

Optical network

IP address

registration

IP borderrouter

UNISONET DCS

IP borderrouter

SONET DCS

Software signaling interface: address registration,lightpath actions (setup, takedown, modify), policycontrol, etc. Software entities residing at border IProuters and border optical network elements

Possibly also IP-like distributedsignaling for lightpath actionrequests inside optical domain

Endpoint reachability

(addresses, VPON IDs),service discovery

UNI

Possibly NMS control(i.e., centralizedresource/policy control)

Multiple client types (e.g., non-IP)supported, such as ATM switches,SONET/SDH network elements,Escon nodes, etc.

BorderOXC

BorderOXC

Core OXC

Modified IP-MPLS protocols orproprietary signaling/routing


18/66


z Overall features All nodes run common routing protocols, maintain same state

Optical nodes assigned IP addresses, i.e., IP router peers

Single instance of distributed routing, flat network hierarchy:

Two-layer opaque LSA databases (flow, information)

Develop opticalextensions, re-use existing MPLS framework:Faster standardization, vendor interoperability

Full peering: all IP end-point addresses exchanged (complex)

O(N2) client mesh, O(N2) client route messaging (scalable)

z UNI-like functional requirements

IP routers directly resolve lightpath requestsI.e., source-based routing via global (LSA) knowledge

Lightpath signaling implicit in end-to-end MPLS LSP control:Via modified RSVP-TE/CR-LDP control messages

Network Models: Peer ModelNetwork Models: Peer Model


19/66



z Various protocol enhancements required IP routing augmented to carry optical link state information

MPLS signaling enhanced for lightpath setup control, etc.

IGP can hide optical internals via forwarding adjacencies:I.e., complete lightpaths advertised as links

Overlap with more encompassing MPS frameworkz Shortcomings and concerns

Nodes maintain unnecessary information:E.g., Routers receive optical LSAs, restoration messaging

Flat-hierarchy cannot scale to large joint IP-optical domains

Opens optical networks internals (proprietary) to client routersE.g., topological details, routing behaviors, etc.

Strictly IP-only, difficult to support legacy non-IP devices:E.g., SONET, ATM support (network migration)

Longer standardization, deployment timeframes


20/66


Network Overview

IP/MPLSclient router

Full peering, IP router (or OXC)notifies OXC (or IP router) of allIP address prefixes (i.e., flatnetwork hierarchy)

Lambda switch routers (SR), switchpurely on wavelengths, i.e., (O-ADMs,OXCs) with IP routing software control(OSPF/IS-IS, CR-LDP/RSVP, etc)

Label edge router (LER) performs forwardequivalent class (FEC) mapping (trafficaggregation function) on to lightpaths, full labelprocessing actions, smaller LSP flow granularities.

Large, granular

optical LSP

IP/MPLSclient router

OXC (SR)OXC (SR)

OXC (SR)

IP and optical domains

Modified IGP and signaling protocols(OSPF/IS-IS, RSVP-TE/CR-LDP)


OXC IP addresses

Router IP addresses


21/66


z Overall features Leverages best-of-both-worlds approach (overlay, peer):

Inter-domain separation, (IP) MPLS protocols re-use

Both IP and optical layers use same (IGP) routing protocol:I.e., different instances(versions): routing, databases

Domain-specific extensions to protocols:E.g., free/available channels, link diversity, analog metrics, etc.

Adapt inter-domainprotocols for end-point reachability exchangePreclude source routing of (optical) lightpathsby packetLSRs

Border routers leak IP addresses (e.g., external BGP):Can further filter/limit prefixes to same user-groups/VPONs

z Benefits and advantages

Good step in migration to full data-centric optical networks

Can employ quickly, fast re-use of IP-based protocols

Highly amenable to the MPS framework

Network Models: Integrated ModelNetwork Models: Integrated Model


22/66


z Network-to-network interface(NNI) requirements Automated interface between opticaldomains (in/out of band)

I.e., border OXCs resolved across domains (wrt IP dest.)

Similar control actions as UNI (request, release, modify, query)

IP addresses must be unique acrossdomains

z Current NNI proposals (further standardization required)

Border gateway protocol(integrated) or MPOA/NHRP (overlay)

BGP for inter-domain IP address exchange:

E-BGP: advertises IP address prefixes between border OXCsI-BGP: advertises IP address prefixes to other border OXCs

Can also use OSPF hierarchy for inter-domain exchange:Two-level, define area border OXCsand summary LSAs

Multi-domain service survivability/recovery:Intra-domain between ingress/egress OXCsInter-domain end-to-end recovery (NNI signaling)

Network Models: NNI ConcernsNetwork Models: NNI Concerns


23/66


Borderrouter

Inter-Domain Interworking

Optical domain A

Border

SR

Optical domain B

Border

SR

Optical domain C

Border

SR

Borderrouter

UNI

UNI

NNI

NNINNI

Intra-domainprotection

Inter-domainprotection

Signaling between border router-border optical network element forpartial (aggregated) end-pointinformation, e.g., integrated model

Signaling between border opticalnetwork elements (lightpathrequest, release, protection, etc.)

Possibly E-BGP or

two-level OSPF forinter-domain end-point exchange

Modified IGP (e.g., OSPF)

propagating optical networktopology and resource updatesinside a domain

Network Models: NNI ConcernsNetwork Models: NNI Concerns

I-BGP for end-point information

propagation between borderOXCs in a given domain


24/66


z International Telecommunications Union(ITU-T) Define completearchitecture, optical transport network(OTN)

Physical layer standards: interfaces, -grid spacing, OSC, etc.

Multiplexing hierarchy (akin to TDM SONET):OCh: Optical channel layer, end-to-end client channels

OMS: Optical multiplex section, multi- signal supportOTS: Optical transmission section, transmission onto media

OCh trail id, trace, protection, monitoring capabilitiesE.g., Optical ring protection proposals, further studies

Digital wrappers framing solution (overhead monitoring, FEC)

Automatic switched optical network(ASON) (via T1X1):E.g., UNI definitions, signaling, etc. (inputs from OIF, IETF)

z Current Status

Various proposals moving towards standards

Strong focus on ASON, possible draft by late 2001

Network Models: ITUNetwork Models: ITU--TT


25/66


z Optical Internetworking Forum(OIF) Based on genuine UNI model (signaled overlay)

End-system discovery, address registration:Border optical nodes distribute (address, port, channel)

Service discovery (network, client capabilities and limitations)

Lightpath attributes (proposed):Id, user group, source (dest) address, framing, bandwidth,directionality, transparency, priority, restoration type, delay, etc

Optical network control performs request resource/policy control

Lightpath actions: request, disconnect, query, modify

Cost-reduced interface specifications (i.e., link-level framing):E.g., very short reach(VSR) interfaces, low-cost parallel/serial

z Current Status

Primary focus on UNI, future NNI work likely

UNI 1.0 specification by November 2000 meeting

Network Models: OIFNetwork Models: OIF


26/66


z Optical Domain Service Interconnect(ODSI) Forum Based on genuine UNI model (signaled overlay):

I.e., no consideration of optical network internals

Provisions to request, release, modify, query bandwidth trails

Uni-directional bandwidth trail parameters:

Size, encoding, priority, protection, delay, jitter, BER, etc Several main network entities provided:

Trail requester, head, tail, optical network controller (ONC)

Third-party signaling, user groups limit connectivity to members

Service discovery, use IP addresses (registration via PPP)

z Current Status Functional, signaling, and MIB specifications complete

Multi-vendor interoperability trials proposed (December 2000)

Network Models: ODSINetwork Models: ODSI


27/66


Network Models: ODSINetwork Models: ODSI

TrailHead

Optical NetworkController (ONC)

TrailRequester

User devices (e.g., IP routers, ATM switches,SONET/SDH cross-connects, Gigabit Ethernetnodes, etc.) source ODSI bandwidth action requestsand comprise trail requester, head, and tail nodes

ODSI control messages (TCP/IPtransport)

ODSI bandwidth (trail) action messages (create,destroy, modify, query). Request actions relayedto ONC via head and tail entities

ONC responses to trail requestersbandwidth actions (e.g., trailacknowledge, trail notification), sentback to trail requester entity.

TrailTail

ONC validates request action and

allocates capacity for bandwidth, residesinside optical network (e.g., co-locatedwith optical networking device such asOXC/WRS, O-ADM).

Point-to-point bandwidthconnection (data)

Sample ODSI Interaction


28/66


OutlineOutline




z Multi-Protocol Lambda Switching









29/66


z IETF Multi-protocol lambda switching(MPS) paradigm Re-use distributed IP-MPLS framework for optical control:

Complements all networking models (overlay, peer, integrated)

Single-layer integration, new optical LSR devices:

Optical lambda-switch routers (SR nodes)

Abstract lightpath to MPLS lambda switched path(LSP):E.g., coarse circuit granularities (OC-48, OC-192, OC-768)

Proposals for all label types (packet, circuit, , fiber):E.g., generalized MPLS(G-MPLS), strong momentum

Arbitrary framing formats (SONET, digital wrappers, GbE)

z

MP

S exploits all key MPLS features Label switching and LSP explicit routing(ER)

Constraint-based routing(CBR) resource engineering

Service (LSP) survivability capabilities (emerging)

MultiMulti--Protocol Lambda SwitchingProtocol Lambda Switching


30/66


Physical Optical LayerModulation, transmission , amplification, wavelength routing/conversion, etc.

E.g., lasers, amplifiers, modulators, fibers

Plane Hierarchies

Digital Framing (optional)Digital framing for packet encapsulation,

possibly w. overhead PM (only link-layer role)E.g., SONET, digital wrappers, GbE

Unified IP-MPLS/MPS Control Plane

Data Plane

IP-MPLS Packets

Packet/cell encapsulationE.g., MPLS shim header, ATM cell

Digital framing is independent ofcontrol plane, since data channelsare orthogonal to control

Possibly lightweight signaling protocols,protection/ restoration functionality

Fast signaling

MPLS/MPS LayerPacket/flow QoS andoptical circuit

routing, protection/recovery, traffic eng.

E.g., IP routers, ATM switches, O-ADM, OXC



31/66


z Parallels between OXCs and LSRs LSP and lightpaths: uni-directional entities, similar semantics:

MPLS swapping: (in port, in label) (out port, out label)MPS swapping: (in port, in ) (out port, out )

Data and control flows are logicallydecoupled

z Differences between packet and optical LSR nodes Optical nodes (OXC, O-ADM) cannot terminate LSPs:

Termination capable(TC)/termination incapable(TI) nodes

Lightpath LSP versus packet LSP granularities/timescales:Fixed rates/long duration vs. mixed granularity/short duration

No parallels for all packetlabel operations:I.e., no merging, limited stacking (fibercross-connect, FXC)

Added data plane orthogonality:

LSR explicitly reads labels, OXC implies from channelOXC control physicallyseparate (OSC, LAN)



32/66


Packet Label Switch Router (LSR)

Link 1

Link 2

Link 3

Output buffersSwitching fabric

3

9

Link 4

Link 5

Link 6

Link 1: label 3 Link 6: label 9

Demux MuxOptical switching fabric

Lambda Switch Router (SR)

Fiber 1

Fiber 2

Fiber 3

Fiber 4

Fiber 5

Fiber 6

Fiber 2: lambda blue Fiber 4: lambda red

Converters(optional)


Control

OSC

Control informationphysically coupled

with data

Control informationphysically decoupled

from data

Ethernet (e.g.,outband control

channel/network)


33/66


Link-state databasew. extensions

Extended IGPprotocols

(OSPF, IS-IS)

Link ManagementProtocol (LMP)

Signaling protocolsw. extensions

(CR-LDP, RSVP-TE)

Constraint-BasedRouting (CBR)

Key Elements Overview


RWA algorithms and traffic engineering (i.e.,virtual topology) control. Can coordinate jointlywith electronic flow (LSP) control.

Wavelength channel signaling:setup and takedown,protection/restoration switchover coordination

Added optical metrics(re-use/extend IGPTLV/MIB definitions)

Topology/resource distribution (e.g.,link bundle information, SRLG,wavelength usages/conversionresources, etc).

Adjacent neighbor discovery,connectivity/state (i.e., link-type, port id, fault localization)


34/66


z Extended interior gateway protocols(IGP) Perform distributedtopology and resource discovery:

I.e., database for lightpath RWA, protection, traffic engineering

Augment existing IGP protocols (e.g., OSFP, IS-IS):Intra-domain opaque link-state updates(LSA)

Extensions required for optical link, node representations:Link type: transparent/translucent, media type, etc

Link bundling: scalable abstraction for large link countsWavelength usages: active, allocated, pre-emptable, reserved

Switching capabilities: static/any-to-any, -conversion, etc.Shared risk link group(SRLG): route diversity information

Update triggers: thresholds to control signaling loads Added requirements for all-optical nodes (w/o -conversion):

Per-link analog metrics (e.g., dispersion, distance, etc.)Per-channelusage (routing scalability concerns)



35/66


z Link management protocol(LMP) (recently proposed) Adjacent neighbor discovery (bi-directional control channel):

Link bandwidth/type and port identifiers, use link bundling

Maintain neighbor connectivity, state (periodic hello messages)

Fault localization (monitoring of bearer/control channels):

E.g., SONET PM overhead, optical power monitoring Added correlation needed for upstream fault indication

Provides information for other MPS protocols:E.g., topological connectivity (IGP), faults (CR-LDP)

z Inter-domain (IP-to-optical) reachability exchange

E-BGP propagates address prefixes between domains

Via dual OSPF routing hierarchy (area border routers, ABR):Summary inter-area LSA, external address-ABR pairing

Scalability concerns (as address count grows):Can use address aggregation, VPON selectivity



36/66


z Signaling requirements for real-time control Extensions to MPLS signaling protocols (RSVP-TE, CR-LDP):

E.g., to perform ER of uni-directional (light)paths

Sample optical lightpath-specific requirements:Bi-directional setup: same path nodes, reduced race conditionsWavelength conversion: client tuning ranges/limitations

Further extensions for survivability:Protection setup information (path/span, shared/dedicated, etc.)Fast fault notification/switchover signaling messages

z Constraint-based routing(CBR)/policy control

Application driver for signaling protocols (little standardization):

Use information from opaque LSA database, policy rules

Optical resource control (e.g., traffic engineering)Lightpath routing (RWA) algorithms, virtual topology control

Re-use COPS protocol for policy control functions:Client/server-based (centralized policy server)



37/66


OutlineOutline





z Lightpath Channel Routing








38/66


LightpathLightpathChannel RoutingChannel Routing

z Routing and wavelength assignment(RWA) algorithms Specify lightpath routes for efficient resource engineering:

Maximize resource utilization, minimize costs, load balance

Various complications/constraints arise

Analog impairments, -conversion, computation times, policy

All-optical RWA concerns (transparency, no

-conversion):Global per- information, analog effects (use probing schemes)

Two classes of algorithms: centralized, distributed

z MPS explicit routing(ER) capability (peer, integrated models)

Allows controlled route selection, specified by MPS CBR

Use extended IGP (LSA) database information:Source routed (computed) or via centralized route server

Provisions for most advanced WDM RWA protocols:I.e., policy, priority, resilience, preemption attributes


39/66


LightpathLightpathChannel RoutingChannel Routing

z Centralized RWA algorithms (all pairs routing) Integer-flow optimization/heuristic formulations, two stages:

Route resolution and wavelength selection (much research)

Lengthy compute times, powerful route servers required:Infrequent/batch lightpath requests, smaller networks

Unscalable for fast arrivals, single-point-of-failure (less robust)

z Distributed RWA algorithms (node pair routing)

Usually shortest-path heuristics routing, source routing

Routing metrics derived from resource (LSA) databaseE.g., # free channels, relative costs, etc (dynamic metrics)

Can be resource inefficient, need optical (re)-engineering

z Hybrid solutions

Distributed routing for handling immediate requests

Central server performs longer-term adjustmentsE.g., lightpath re-routing/re-tuning for efficiency


40/66


OutlineOutline






z Service Survivability







41/66


Service SurvivabilityService Survivability

z Optical layer survivability schemes Paramount concern due to extreme degree of multiplexing:

I.e., Single fiber can now carry 64x more voice calls

Service outage penalties can be substantial

Fast, expedient protection is possible (ms range)

Multiple, flexible survivability service definitions possible:I.e., compliments wide range of IP traffic (realtime, data)

Very scalable, cost-effective compared to higher-layer recovery:I.e., large aggregates switched (fibers, wavelengths)

z Current status

Protection and restoration schemes proposed (IETF, OIF):Protection schemes receiving most attention

Closely inter-related to performance monitoring schemes

Standards are still lacking, multi-layer concerns


42/66



z Fiber/span protection schemes (OMS level) Protection fibers pre-determined (linear, ring, mesh topologies)

Very scalable (less signaling), fast recovery (up to order ms)

Unable to achieve service differentiation between lightpaths

Multiplexing gains (lower priority working on protection spans)

z Lightpath protection schemes (OCh level) Protection lightpath routes pre-determined (e.g., via MPS ER)

Receiver-based end-to-end path (ring) switching (1+1 equiv.)

Signaled lightpath recovery (i.e., non-receiver-based):

Mesh: Path/sub-path protection switching

Rings: Near/far-side path switching (SONET BLSR type) Multiple levels of wavelength sharing, improved efficiency:

Dedicated and shared protection wavelengths (1:1, M:N)

Recovery timescales increase w. hop counts

Translucent monitoring for sub-path switching?


43/66



Ring Topology Mesh Topology

DC

A B

Failed channel sub-path (near-side)

ring switch(i.e., A-B-D)

Failed channelpath (far-side)

ring switch(i.e., A-C-D)

A

B

D

C

Failed channelpath switch(i.e., A-B-E)

E

F

Failed channelsub-path switch(i.e., A-B-D-E)

DC

A B

All wavelengthsspan switched

(i.e., A-B-D for red,B-D for green)

A

B

D

C

All wavelengths spanswitched (i.e., A-C-D-E)

E

Multi-fiberdiversity

F

PathSwitching

Span

Switching

Working:A-B-D (red)Working:A-C-D-E (red)

Working:A-B-D (blue)B-D (red)

Working:A-C-D-E (red)


44/66


z Integration with MPS framework Possibly extend MPLS LSP protectionto cover lightpaths:

Optical (electronic) monitoring but MPLS performs switchovers

Generic protection switch/merge nodes(PSL/PML) defined

New MPLS messages/priorities:

Fault indication signal(FIS), PSL/PML identification, etc. Fast routing reverse notification tree(RNT) (less routing delays)

Possibly new specialized protocols emerging

z RWA implications for lightpath protection

Joint-RWA of working, protection lightpaths at setup time

Protection channels must be hopand SRLG-disjoint:I.e., Constrained to exclude all working-path fibers, nodes

All-optical RWA restricts further (no -conversion)

Compute complexities, can use graph-pruning:Possibly use a fast route server (centralized)?



45/66


Dedicated 1:1 Protection

Working connection(solid)

Dedicated protectionwavelengths (dotted)

Shared Protection

Shared protectionwavelength on link

A-E (dotted)

Working connection(solid)


Example: Dedicated and Shared Wavelength Protection

A

B

C

D

E

F

G

A

B

C

D

E

F

G

Source node (e.g.,MPLS protectionswitch SR, PSL)

Destination node(e.g., MPLS protection

merge SR, PML)

Working 1: A-B-G,Protection 1: A-E-G

Working 2: A-C-FProtection 2: A-D-F

Working 1: A-B-G,Protection 1: A-E-G

Working 2: A-C-FProtection 2: A-E-F


46/66



z Optical restoration schemes Dynamic post-fault signaled recovery:

I.e., backup (sub)path re-computation via message flooding

Can also provide multiple service levels (i.e., sharing)

Path re-computation also needs node/SRLG diversity information

Longer recovery timescales (sub-second or more):Signaling delays, repair algorithm compute times

z Issues and concerns

Lightpath RWA search complexities/delays:Use pruning, pre-stored candidate paths, fast route servers

Reduce recovery signaling timescales:Sub-path repair, selected flooding, fault message priorities

Better suited for distributed recoverysignaling model

Standardization slow,likely longer-term deployment


47/66


48/66


OutlineOutline





zzz

LightpathLightpathLightpathChannel RoutingChannel RoutingChannel Routing


z Performance Monitoring


zzzFuture EvolutionsFuture EvolutionsFuture Evolutions




49/66


z Fast fault detection/localization is crucial First phase of any service recovery, greatly impacts timescales

Currently only electronic schemes are accepted by carriers

MPS lightpath recovery is complimentary to monitoring

z Electronic performance monitoring (overlay, peer models)

Employ digital framing, opaque/translucent (i.e., O/E) nodes:E.g., SONET (SDH) overhead, digital wrappers

Monitoring bytes indicate errors/problems:SONET B1 and J0 bytes, digital wrappers FDI/BDI bytes

Can achieve SONET-like recovery timescales (


50/66


z Optical performance monitoring Optical monitoring, transparent nodes

I.e., Extract and analyze low-loss tap signal (1%)

Permits more efficient/less rigid framing formats (e.g., GbE)

Compare various operating parametersagainst thresholds

Minimal set of parameters (suggested):Power, signal-to-noise ratio (O-SNR), bit-error-rate (BER)

Additional possibilities:

Dispersion, cross-talk, Q-factor, drift, transients, jitter

Power level monitoring available: very fast detection (ms)

z

Shortcomings and concerns Threshold/timescale concerns (i.e., inactivity vs. failure)

Per-wavelengthmonitoring complexities:Optical component costs, board space limitations

Lack of standards poses deployment hurdles

Performance MonitoringPerformance Monitoring


51/66


z Packet level monitoring Re-use packet-based re-fresh timer mechanisms:

Keep-alive timers, hello timers (OSPF, LMP)Fast-pinging techniques (1000s messages/sec)

Usually used for IP-level restoration techniquesCan be also applied to re-route lightpath circuits

Sub-second detection timescales (hundreds of ms)

SONET-like timescales not required for most IP traffic

z Shortcomings and concerns

Signaling overhead, packet processing delay concerns

Non-OSC wavelengthmonitoring (transparency concerns):Control message insertion/extraction in data wavelengths

Realistically for pure IP-control-only networks:E.g., as yielded by peer or integrated models

Performance MonitoringPerformance Monitoring


52/66


OutlineOutline





zzz




z Traffic Engineering

zzz

Future EvolutionsFuture EvolutionsFuture Evolutions




53/66


z Considerations and objectives IP data traffic has large variations (large inefficiencies/overloads)

Must maximize network resource efficiencies:I.e., allow more customers, increased revenues

Requires continual tuning of network traffic performance:

E.g., ensure user QoS/SLA requirements Adjust resource partitions between working/protection

Generally employed over longer timescales (hours, days)

Fits well under MPS CBR framework

z Limitations of existing routing protocols

No resource/congestion considerations (e.g., OSPF):E.g., simple hop metrics for regular shortest-path routing

Longer paths ignored, could utilize idle resources (efficient)

Need additional functionalitiesTraffic measurement, prediction, route control

Traffic EngineeringTraffic Engineering


54/66


z Active traffic measurement Traffic monitoring and pre-processing at routers/LSRs:

E.g., average queues, drop rates, per-class throughputs

Generate IP-router network traffic-matrixPer-class measurements (DiffServ+MPLS paradigm)

Complexity can be high, timescales must be chosen carefullyz Resource prediction/action trigger computations

Bandwidth predictions based upon history:E.g., use simple low-pass filtering to reduce oscillations

Control action triggers:E.g., multi-level queue thresholds and/or rate overloads

Two tiers of traffic engineering actions:IP-flow level for small/moderate adjustmentsOptical level for more sizeable/large adjustments



55/66



Raw input traffic loadmeasurements

Traffic measurement and basicfiltering/pre-processing

Filtered traffic metrics (e.g., averagethroughputs, buffer lengths, drop rates, etc.)

Resource prediction/trigger computation

IP flow-level traffic engineering:flow re-routing/re-classification

Optical-level traffic engineering:virtual topology adjustment

IP flow routes,priorities, etc.

Lightpath routes,priorities, etc.

Unified IP flow/opticallightpath traffic engineeringentity for peer model

Information Flow Process

Topology, resource,policy, faultinformation


56/66


z IP-flow level traffic engineering (i.e., data packet level) Add new parallel paths, re-distribute traffic between routes:

E.g., optimized multi-path(OMP) schemes

Re-route flows between routers (network-level load balancing)

Re-allocate capacity/buffers (node-level load balancing)

Re-classify traffic flows (priorities, packet discarding) Adjust virtual topology, i.e., packet hop counts (buffering)

E.g., bandwidth setup/takedown/modify via optical layer

Residual traffic re-routing after lightpath takedown

z Optical-layer traffic engineering: virtual topology control

Combine IP traffic engineering w. optical provisioning:Routers dial-up bandwidth as needed (i.e., new circuits)

IP traffic engineering serves as RWA driver application

Re-route/drop lightpaths to improve efficiencies

Re-tune lightpath lambdas (centralized, off-line)



57/66


Time

MeasuredAverage

Load

Traffic load average declinesbelow very low threshold, releaselightpath, layer-three re-routing ofany residual traffic

VeryLow

VeryHigh

Sample Queue Hysterisis Control

Traffic load average rises above veryhigh threshold, request lightpath, re-directoverflow traffic onto new lightpath

Longer measurement timescales (typically hours, days) toprevent excessive oscillatory behavior (inefficiencies)


Overload

Desired Load

Underload

High

Low

Traffic load average rises abovehigh threshold, create new (or re-route) packet flow paths

Traffic load average falls below low

threshold, takedown (or re-route)packet flow paths


58/66


z Centralized network controller (suited for overlay model) For smaller networks, large timescales, complex optimizations:

I.e., given traffic matrix, resolve LSP/lightpath topologies

Less resource synchronization/lock-out problems

Single point of control (failure) poses concern

Complicated information transfer to controller:E.g., router measurements, LSAs, network alarms, etc

z Distributed traffic engineering (suited for peer model)

Localized decisions (scalable), heuristic/routing algorithms:E.g., IP routers andOXCs can re-distribute loadings

Robust, suited for distributed MPLS CBR solution:Very new area, much research work remains to be done

Multi-vendor interoperability may require standards:I.e., control algorithms (beyond LSA definitions)



59/66


OutlineOutline

zzz

IntroductionIntroductionIntroduction




zzz





z

Future Evolutions




60/66


Future EvolutionsFuture Evolutions

zNew switching paradigms Eventual wavelength exhaust as traffic growth continues:

I.e., due to circuit-switching inefficiencies for bursty IP traffic

Must reduce wavelength provisioning timescales (ms to ns)

I.e., statistical multiplexing gains, share scarce resources

Re-emergence of (optical) packet switching in the core?

z Optical packet switching(OPS) designs

Utilize high-speed electronics to match optical line rates:E.g., electronic header processing overlap w. payload transfer

Multi-channel (DWDM) optical line rate challenges:Fixed payloads, guard-time inefficiencies, massive parallelism

Stringent high-speed header/payload synchronization

Packet buffering is major concern (to avoid O-E conversion):

Small fiber loops, -conversion, deflection routing (complex)

Breakthroughs in optical processor technology?


61/66



zOptical burst switching(OBS) designs Decouple header-payload synchronization, variable payloads

Switch action scheduled just before burst arrival (efficient)

Burst contention degrades performance, buffering required

z Hybrid switching designs

Unify packet, wavelength, and fiber switching in single box:E.g., fiber-wavelength-packet(FWP) node, fiberpathconcept

Different levels switch on different timescales:E.g., wavelength switching for traffic engineering or protection

Collapses equipment/hierarchy at large network core points:Already emerging at edge/access, optical edge devices(OED)

z MPLS/MPS can support emergent paradigms (G-MPLS)

Multi-level aggregation/switching (flow, burst, , band, fiber)

Extendible (routing, signaling, traffic engineering)E.g., MPLS applied to optical burst switching


62/66



1980

Ag

gregateSystemT

hro

ughput(bits/sec)

106

107

108

109

1011

1012

1013

1985 1990 1995 2000 2005

1010

10 Gb/s, 40-100

wavelengths

2.5 Gb/s, 4-20

wavelengths

40 Gb/s, 40-100wavelengths

Single-channel

TDM systems

Multi-channeloptical systems

Timeline

Megabit

Gigabit

Terabit

1014

10

15

Petabit

ATM

switches

PDH

systems

Giga/tera-

bit routers

First generation

WDM systems

Early SONET

ADMs

Ultra dense

DWDM systems

Glass ceiling (Moores Law)

?Hybrid designs (fiber,

lambda, burst-packet)

1-2.5 Gb/sport speeds

OC-3 (155 Mb/s)/

OC-12 (622 Mb/s)

OC-3

(155 Mb/s)

DS-1 (1.54 Mb/s)-

DS-3 (44.73 Mb/s)

SONET

ADM/DCS

OC-48 (2.5 Gb/s),

OC-192 (10 Gb/s)


63/66


OutlineOutline

zzz

IntroductionIntroductionIntroduction




zzz

LightpathLightpathLightpathChannel Routing

Channel RoutingChannel Routing




zzz

Future EvolutionsFuture EvolutionsFuture Evolutions

z Conclusions



64/66


ConclusionsConclusions

zNew provisioning paradigms for optical networks TDM multi-layered models slow, unscalable, inefficient

Wavelength switching timescales will decrease

Weeks days hrs min sec ms ns (?)

z Overlay approaches

Optical UNI, de-couple IP and optical signaling control

Standardization efforts maturing, good transitional approach

z Peering and integrated approaches

Expand IP-based provisioning/control plane framework

Most direct integration, flat and hierarchical solutions

z MPS solution Powerful framework, lends faster interoperability

Routing, signaling, traffic engineering, survivability, etc.

Amenable to many future evolutions


65/66


ReferencesReferences

z N. Ghani, et al, On IP Over WDM Integration, IEEE Communications Magazine, March 2000.

z B. Rajagoplan, D. Pendarakis, D. Saha, S. Ramamurthy, IP Over Optical Networks: ArchitecturalAspects, IEEE Communications Magazine, September 2000.

z N.Chandhok, et al, IP Over Optical Networks, IETF Draft, draft-osu-ipo-mpls-issues-00.txt, July2000..

z J. Luciani, et al, IP Over Optical Networks-A Framework, IETF Draft, draft-ip-optical-framework-00.txt, February 2000.

z D. Awduche, et al, Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering ControlWith Optical Crossconnects, IETF Draft, draft-awduche-mpls-te-optical-01.txt, November 1999.

z

N. Ghani, Lambda-Labeling: A Framework for IP Over WDM Using MPLS, Optical NetworksMagazine, April 2000.

z L. Ceuppens, Multiprotocol Lambda Switching Comes Together, Lightwave Magazine, Aug. 2000.

z O. Aboul-Magd, et al, Signaling Requirements at the Optical UNI, IETF Draft, draft-bala-mpls-optical-uni-signaling-00.txt, July 2000.

z J. Hahm, K. Lee, M. Carson, Control Mechanisms for Traffic Engineering in Optical Networks, IETFDraft, draft-hahm-te-optical-00.txt, July 2000.

z D. Pendarakis, B. Rajagopalan, D. Saha, Routing Information Exchange in Optical Networks, IETFDraft, draft-prs-optical-routing-00.txt, March 2000.

z P. Ashwood,et al,Generalized MPLS-Signaling Functional Description, IETF Draft, draft-ashwood-generalized-mpls-signaling-00.txt, August 2000.

z K. Kompella, et al, Extensions to IS-IS/OSPF and RSVP in Support of MPL(ambda)S, IETF Draft,draft-kompella-mpls-optical-00.txt, August 2000.

z J. Lang, et al, Link Management Protocol (LMP), Internet Draft, draft-lang-mpls-lmp-01.txt, July2000.


66/66

ReferencesReferences

z N. Ghani, Survivability Provisioning in Optical MPLS Networks, 5thEuropean Conference on

Networks and Optical Communications, Stuttgart, Germany, June 2000.z L. Ceuppens, et al, Performance Monitoring in Photonic Networks in Support of MPL(ambda)S,

IETF Draft, draft-ceuppens-mpls-optical-00.txt, September 2000.

z L. McAdams, J. Yates Lightpath Attributes and Related Service Definitions, IETF Draft, draft-mcadams-lightpath-attributes-00.txt, September 2000.

z N. Ghani, et al, COPS Usage for ODSI, IETF Draft, draft-ghani-cops-odsi-00.txt, July 2000.

z K. Liu, C. Liu, J. Wei, Overlay versus Integrated Traffic Engineering for IP/WDM Networks, IEEEGlobecom 2000, San Francisco, CA.

z International Telecommunication Union (ITU-T), Architecture of Optical Transport Networks,Recommendation G.872, Feb. 1999.

z H. Zang, J. Jue, B. Mukherjee, Review of Routing and Wavelength Assignment Approaches forWavelength-Routed Optical WDM Networks, Optical Networks Magazine, January 2000.

z S. Chaudhuri, et al, Control of Lightpaths in an Optical Network, IETF Draft, draft-chaudhuri-ip-olxc-control-00.txt, Feb. 2000.

z S. Verma, H. Chaskar, R. Rayadurgam, Optical Burst Switching: A Viable Solution for the Terabit IPBackbone, IEEE Network Magazine, November/December 2000.

z D. Hunter, I. Andonovic, Approaches to Optical Internet Packet Switching, IEEE Communications

Magazine, September 2000.

Documents

Optical Nasir