IP Over Optical - people.eecs.berkeley.eduwlr/228a/optical-Nasir.pdfØLasers (2.5 Gb /s, 10 Gb /s, tunability emerging) ØAmplifiers with improved gains, advanced power equalization

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


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


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 networking applications emerging

Ø “Optical building blocks exist, the focus now is on developing intelligence to interwork with other (IP) devices”



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 layer

I.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)



Physical Optics Layer

High-Level Overview of Network Integration Models

WDM Layer

Layering (overlay) approaches

SONET

ATM

IP

IP

IP

Direct MPλλS-based approach

IPSONET

ATM

IP

IP

Traditional SONET-based approaches


OutlineOutline

zzz IntroductionIntroductionIntroduction

z Traditional Approaches

zzz Network ModelsNetwork ModelsNetwork Models

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

zzz Lightpath Lightpath Lightpath Channel 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


Traditional ApproachesTraditional Approaches

z Largely based upon existing TDM (SONET) infrastructuresØ Point-to-point DWDM 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



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

Wavelength laser transponders

DemuxMux

Wideband receivers

Gigabit IP Router

IP routing protocols (OSPF, BGP)

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

Gigabit IP Router

SO

NE

T

SO

NE

T

Point-to-point DWDM links (linear or ring

SONET topologies)



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)

Ø Each layer 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


OutlineOutline


zzz Traditional ApproachesTraditional ApproachesTraditional Approaches

z Network Models










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 lightpath entities

Ø 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


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Ø Static and signaled overlay 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


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


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):

Border routers and border OXC’s, 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


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 and optical layers is via a software UNI (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



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?



Architecture Overview

Optical network

IP address registration

IP border router

UNISONET DCS

IP border router

SONET DCS

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

Possibly also “IP-like” distributed signaling for lightpath action requests inside optical domain

Endpoint reachability (addresses, VPON ID’s),

service discovery

UNI

Possibly NMS control (i.e., centralized resource/policy control)

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

Border OXC

Border OXC

Core OXC

Modified IP-MPLS protocols or proprietary signaling/routing


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 optical extensions, 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 requests

I.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



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 MPλS frameworkz Shortcomings and concernsØ Nodes maintain unnecessary information:

E.g., Routers receive optical LSA’s, restoration messaging

Ø “Flat-hierarchy” cannot scale to large “joint IP-optical” domainsØ Opens optical network’s internals (proprietary) to client routers

E.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


Network Overview

IP/MPLS client router

Full peering, IP router (or OXC) notifies OXC (or IP router) of all IP address prefixes (i.e., “flat network hierarchy”)

Lambda switch routers (λSR), switch purely on wavelengths, i.e., (O-ADM’s, OXC’s) with IP routing software control (OSPF/IS-IS, CR-LDP/RSVP, etc)

Label edge router (LER) performs forward equivalent class (FEC) mapping (traffic aggregation function) on to lightpaths, full label processing actions, smaller LSP flow granularities.

Large, granular “optical LSP”

IP/MPLS client 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


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-domain protocols for end-point reachability exchangePreclude source routing of (optical) lightpaths by packet LSRs

Ø Border routers “leak” IP addresses (e.g., external BGP):Can further filter/limit prefixes to same user-groups/VPON’s

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 MPλS framework

Network Models: Integrated ModelNetwork Models: Integrated Model


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

I.e., border OXC’s resolved across domains (wrt IP dest.)Ø Similar control actions as UNI (request, release, modify, query)

Ø IP addresses must be unique across domains

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 OXCs” and summary LSAs

Ø Multi-domain service survivability/recovery:Intra-domain between ingress/egress OXC’sInter-domain end-to-end recovery (NNI signaling)

Network Models: NNI ConcernsNetwork Models: NNI Concerns


Border router

Inter-Domain Interworking

Optical domain A

Border λSR

Optical domain B

Border λSR

Optical domain C

Border λSR

Border router

UNI

UNI

NNI

NNINNI

Intra-domain protection

Inter-domain protection

Signaling between border router-border optical network element for partial (aggregated) end-point information, e.g., integrated model

Signaling between border optical network elements (lightpath request, release, protection, etc.)

Possibly E-BGP or two-level OSPF for inter-domain end-point exchange

Modified IGP (e.g., OSPF) propagating optical network topology and resource updates inside a domain

Network Models: NNI ConcernsNetwork Models: NNI Concerns

I-BGP for end-point information propagation between border OXC’s in a given domain


z International Telecommunications Union (ITU-T)Ø Define complete architecture, 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 channelsOMS: 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


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


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


Network Models: ODSINetwork Models: ODSI

Trail Head

Optical Network Controller (ONC)

Trail Requester

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

ODSI control messages (TCP/IP transport)

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

ONC responses to trail requester’s bandwidth actions (e.g., trail acknowledge, trail notification), sent back to trail requester entity.

Trail Tail

ONC validates request action and allocates capacity for bandwidth, resides inside optical network (e.g., co-located with optical networking device such as OXC/WRS, O-ADM).

Point-to-point bandwidth connection (data)

Sample ODSI Interaction


OutlineOutline




z Multi-Protocol Lambda Switching









z IETF Multi-protocol lambda switching (MPλλS) 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


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/MPλλS” Control Plane

Data Plane

IP-MPLS PacketsPacket/cell encapsulation

E.g., MPLS shim header, ATM cell

Digital framing is independent of control plane, since data channels are orthogonal to control

Possibly lightweight signaling protocols, protection/ restoration functionality

Fast signaling

MPLS/MPλλS LayerPacket/flow QoS and optical circuit

routing, protection/recovery, traffic eng.E.g., IP routers, ATM switches, O-ADM, OXC



z Parallels between OXC’s and LSR’sØ LSP and lightpaths: uni-directional entities, similar semantics:

MPLS swapping: (in port, in label) ⇒ (out port, out label)MPλS swapping: (in port, in λ) ⇒ (out port, out λ)

Ø Data and control flows are logically decoupledz Differences between packet and optical LSR nodesØ Optical nodes (OXC, O-ADM) cannot terminate LSP’s:

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 packet label operations:I.e., no merging, limited stacking (fiber cross-connect, FXC)

Ø Added data plane orthogonality:LSR explicitly reads labels, OXC implies from λ channelOXC control physically separate (OSC, LAN)



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 information physically coupled

with data

Control information physically decoupled

from data

Ethernet (e.g.,outband control

channel/network)


Link-state database w. extensions

Extended IGP protocols

(OSPF, IS-IS)

Link ManagementProtocol (LMP)

Signaling protocolsw. extensions

(CR-LDP, RSVP-TE)

Constraint-Based Routing (CBR)

Key Elements Overview


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

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

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

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

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


z Extended interior gateway protocols (IGP)Ø Perform distributed topology 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, reservedSwitching capabilities: static/“any-to-any”, λ-conversion, etc.Shared risk link group (SRLG): route diversity informationUpdate 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-channel usage (routing scalability concerns)



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 MPλS 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



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)



OutlineOutline





z Lightpath Channel Routing








Lightpath Lightpath Channel 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 ariseAnalog 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 MPλλS explicit routing (ER) capability (peer, integrated models)Ø Allows controlled route selection, specified by MPλS 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


Lightpath Lightpath Channel 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)-engineeringz Hybrid solutionsØ Distributed routing for handling “immediate” requests

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


OutlineOutline






z Service Survivability







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



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 MPλS 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 switchingRings: 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?



Ring Topology Mesh Topology

DC

A BFailed channel sub-

path (near-side) ring switch

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

Failed channel path (far-side)

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

A

B

D

C

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

E

F

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

DC

A BAll wavelengths span switched

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

A

B

D

CAll wavelengths span

switched (i.e., A-C-D-E)

E

Multi-fiber diversity

F

PathSwitching

SpanSwitching

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)


z Integration with MPλλS frameworkØ Possibly extend MPLS LSP protection to 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 hop and 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)?



Dedicated 1:1 Protection

Working connection (solid)

Dedicated protection wavelengths (dotted)

Shared Protection

Shared protection wavelength 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 protection switch λ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



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 recovery signaling model

Ø Standardization slow,likely longer-term deployment



z Interference concerns (mainly for overlay approach)Ø Most routers still use IP to SONET (even ATM) mappings

Ø Higher-layer protocols have existing recovery mechanismsE.g., SONET APS (fast), IP re-routing (slow), ATM rings

Ø Destructive interference degrades responsiveness/efficiency“All layers do not switch over to same backup resource”

z “Multi-layer” escalation strategies, avoid “collisions”Ø Bottom-up approach (e.g., “hold-off” timers):

Attempt optical layer recovery first (more scalable)

Ø Top-down approach: higher (“client”) layers attempt first:E.g., SONET APS, or (MPLS) LSP flow re-routing

Ø Complex timing, topological, inter-layer signaling:E.g., full path switching or restoration is slower

Ø Need standardization, only simple early solutions:E.g., No SONET (or optical) layer recovery


OutlineOutline







z Performance Monitoring






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

Ø Currently only “electronic” schemes are accepted by carriers

Ø MPλS lightpath recovery is complimentary to monitoringz 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 (<50ms)Ø Signaling channel built in to monitoring frame format (inband)

z Shortcoming and concernsØ Increased cost and complexity (per-hop, per-λ O-E conversion)

Very unscalable for large channel/fiber counts

Ø Payload mappings required (restrictive for data)

Performance MonitoringPerformance Monitoring


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 parameters against 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-wavelength monitoring complexities:Optical component costs, board space limitations

Ø Lack of standards poses deployment hurdles



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

Keep-alive timers, hello timers (OSPF, LMP)“Fast-pinging” techniques (1000’s 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 wavelength monitoring (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



OutlineOutline








z Traffic Engineering





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 MPλS CBR frameworkz 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


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-matrix”Per-class measurements (DiffServ+MPLS paradigm)

Ø Complexity can be high, timescales must be chosen carefully

z 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




Raw input traffic load measurements

Traffic measurement and basic filtering/pre-processing

Filtered traffic metrics (e.g., average throughputs, 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/optical lightpath traffic engineering entity for peer model

Information Flow Process

Topology, resource, policy, fault information


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)



Time

Mea

sure

d A

vera

ge

Lo

ad

Traffic load average declines below very low threshold, release lightpath, layer-three re-routing of any residual traffic

Very Low

Very High

Sample Queue Hysterisis Control

Traffic load average rises above very high threshold, request lightpath, re-direct overflow traffic onto new lightpath

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


Overload

Desired Load

Underload

High

LowTraffic load average rises above high threshold, create new (or re-route) packet flow paths

Traffic load average falls below low threshold, takedown (or re-route) packet flow paths


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, LSA’s, network alarms, etc

z Distributed traffic engineering (suited for peer model)Ø Localized decisions (scalable), heuristic/routing algorithms:

E.g., IP routers and OXCs 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)



OutlineOutline









z Future Evolutions




Future EvolutionsFuture Evolutions

z New 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?



z Optical 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, fiberpath concept

Ø 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/MPλλS 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



1980

Ag

gre

gat

e S

yste

m T

hro

ug

hp

ut

(bit

s/se

c)

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-100 wavelengths

Single-channel TDM systems

Multi-channel optical systems

Timeline

Megabit

Gigabit

Terabit

1014

1015

Petabit

ATM switches

PDH systems

Giga/tera-bit routers

First generation WDM systems

Early SONET ADM’s

Ultra dense DWDM systems

“Glass ceiling” (Moore’s Law)

?Hybrid designs (fiber, lambda, burst-packet)

1-2.5 Gb/s port 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)


OutlineOutline










z Conclusions



ConclusionsConclusions

z New provisioning paradigms for optical networksØ TDM multi-layered models slow, unscalable, inefficient

Ø Wavelength switching timescales will decreaseWeeks ⇒ 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 MPλλS solutionØ Powerful framework, lends faster interoperability

Ø Routing, signaling, traffic engineering, survivability, etc.

Ø Amenable to many future evolutions


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: Architectural

Aspects,” IEEE Communications Magazine, September 2000.z N.Chandhok, et al, “IP Over Optical Networks,” IETF Draft, draft-osu-ipo-mpls-issues-00.txt, July

2000..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 Control

With 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 Networks

Magazine, 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,” IETF

Draft, draft-hahm-te-optical-00.txt, July 2000.z D. Pendarakis, B. Rajagopalan, D. Saha, “Routing Information Exchange in Optical Networks,” IETF

Draft, 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, July

2000.


ReferencesReferences

z N. Ghani, “Survivability Provisioning in Optical MPLS Networks,” 5th European 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,” IEEE

Globecom 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 for

Wavelength-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 IP

Backbone,” IEEE Network Magazine, November/December 2000.z D. Hunter, I. Andonovic, “Approaches to Optical Internet Packet Switching,” IEEE Communications

Magazine, September 2000.

Documents

IP Over Optical - people.eecs.berkeley.eduwlr/228a/optical-Nasir.pdfØLasers (2.5 Gb /s, 10 Gb /s, tunability emerging) ØAmplifiers with improved gains, advanced power equalization