IP over Optical Networks

1
IP over Optical Networks

• Debanjan Saha
• Bala Rajagopalan
• dsaha, braja_at_tellium.com

2
BOF Objectives

• Determine areas of priority for operators in
• IP-centric control of optical networks
• IP over optical network service architectures
• New services applications
• Traffic engineering network re-configuration
• Others

3
Summary

• Motivation
• IP over optical network model
• IP-centric control plane for optical networks
• MPLS signaling for optical networks
• IP routing protocol extensions for optical
  networks
• Optical internetworking
• IP over optical networks
• Service models
• Traffic engineering
• Discussion

4
Benefits of Optical Networking

• Build Networks for 2/3s less
• Optical Meshes are 50 more efficient than TDM
  Rings
• Eliminate SONET/DCS Equipment Layer
  
• Dynamic Lambdas
• Fast provisioning
• Automatic restoration

5
Applications for Dynamic Lambdas

• Reconfigure Network to changing traffics
• Add lambdas on demand between IP Routers
• Tune IP layer topology with changing traffic
  patterns
• Just in time lambdas
• Dynamic Optical Virtual Private Network (OVPNs)
• Shared ls for bandwidth efficiency
• Automatic lightpath restoration
• Restore at Layer 1 instead of Layer 3
• Simplify restoration from large scale failures
• e.g. 100s of lambdas

6
Dynamic Lambdas Routers request Dynamic l
Step 1 - Request l Step 3 - Release l
Step 2 - OXC Provides l
Optical Subnet
Router Network
Optical Subnet
Router Network

• Routers experience congestion
• Step 1 - Router requests additional l to relieve
  congestion
• Step 2 - Optical Switches dynamically add l
  between congested routers
• Traffic Demand Changes
• Step 3 - Optical Switches reconfigure l

7
Tune IP layer topology to changing traffics
Optical Network
Optical Network
Subnet B
Subnet B
Subnet A
Subnet C
Subnet C

• IP Layer Traffic Patterns Change
• Step 1- Add new l from A to B
• Step 2 - Delete l from A to C

8
IP over Optical Network Model
MP?S for signaling and routing within the optical
network
Router Network
Optical Network
NNI
NNI
Optical Path
End-to-end path (LSP)
9
IP-Centric Control of Optical Networks

• Ingredients
• IP addressing for optical network nodes (and
  termination points)
• MPLS-based signaling for lightpath provisioning
• IP routing protocols adapted for resource
  discovery
• Route computation with resource optimization
• Restoration signaling???

10
What is the MP?S approach?

• Each OXC is considered the equivalent of an MPLS
  Label-Switching Router (LSR)
• MPLS control plane is implemented in each OXC
• Lightpaths are considered similar to MPLS
  Label-Switched Paths (LSPs)
• Selection of ?s and OXC ports are considered
  similar to selection of labels
• MPLS signaling protocols (e.g., RSVP-TE, CR-LDP)
  adapted for lightpath establishment
• IGPs (e.g., OSPF, ISIS) with optical extensions
  used for topology and resource discovery

11
Optical Network Functions

• Dynamic provisioning of lightpaths
• Just-in-time provisioning
• Path selection with constraints
• Protection restoration of lightpaths
• Protection paths with appropriate service levels
• Node link disjoint primary protection paths
  for resiliency
• Shared protection paths for cost savings
• Fast restoration of lightpaths after the failure

12
Protocols for Realizing Optical Network Functions

• Provisioning protocols
• Automatic neighbor discovery
• Neighbor Discovery Protocol
• Link Management Protocol
• Topology discovery
• OSPF with optical extension
• IS-IS with optical extensions
• Signaling for path establishment
• RSVP-TE, CR-LDP with optical extensions
• Generalized MPLS
• Restoration Protocols
• Proprietary techniques

13
Physical Topology
O2
O1
Optical Network
Router Network
O5
Optical Network
Router Network
O3
O4
14
Topology Abstraction
SRG 1
O1
O2
NDP
Router Network
Optical Network
UNI
NDP
SRG 2
SRG 3
O5
NDP
NDP
NDP
NDP
Optical Network
SRG 4
Router Network
SRG 5
NDP
UNI
NDP
O4
O3
SRG 6
15
Neighbor Discovery
NDP allows adjacent OXCs to determine IP
addresses of each other and port-level local
connectivity information (i.e., port X in OXC
O1 connected to port Y in OXC O2) (IETF Status
Link Management Protocol (LMP) is being
considered)
10
Primary
Up
OC-48
9.2.1.3
1
Drop
F123, C231
Backup
Up
OC-192
F123, C231
123
2
Network
8.4.1.3
11.3.1.3
Primary
Network
SF
345
OC-48
1023
F234, C251
129.2.1.3
15
Primary
Up
OC-48
1024
Network
F234, C231
Port State Database of O1
16
Topology Discovery with OSPF
Router/ Optical LSA
O2
O1
Summary LSA
OSPF Area 0.0.0.3
Router Network
UNI
O5
OSPF Area 0.0.0.2
Router Network
UNI
Summary LSA
O4
O3
OSPF Area 0.0.0.1
17
OSPF Extensions

• Recognition of optical link types
• Link bundling
• Multiple, similar links between OXCs are
  abstracted as a single link bundle
• Composition of link bundle described by
  parameters
• Single adjacency maintained between OXCs
  regardless of the number of links
• Bundling considerations in preliminary stages in
  IETF

18
Example Scenario
O1
O2
SRLG S1
5 OC-48, 2 OC-192, 2 10G E/N
SRLG S2
5 OC-48, 5 OC-192
19
Desired Bundling Structure
O1
O2
Resource sub-bundle 1
5 OC-48, S1
Resource sub-bundle 2
2 OC-192, S1
Resource sub-bundle 3
2 10G E/N, S1
Single bundle between nodes
Resource sub-bundle 4
5 OC-48, S2
Resource sub-bundle 5
5 OC-192, S2
20
OSPF Extensions

• New lightpath computation algorithms
• Path computation based on lightpath attributes
  and constraints
• Proprietary algorithms for efficiency
• Algorithms not considered in IETF
• Source-routing methodology
• Differs from traditional OSPF
• Considered in IETF as part of RSVP-TE/CR-LDP
  extensions
• Reduction of link state propagation overhead
• Thresholds for reducing link state propagation
  overhead
• No framework yet in the IETF

21
Link State Advertisements
22
Link State Database
23
Routing Across the NNI BGP

• E-BGP is used between adjacent border OXCs in
  different sub-networksI-BGP is used between
  border OXCs in the same sub-network
• External addresses are passed between
  sub-networks, with indication of egress border
  OXC information
• Routing policies may be applied, as per BGP
  features

E-BGP
E-BGP
I-BGP
Sub-network 1
Sub-network 2
Sub-network 3
24
Some Issues to Consider

• What other information must be exchanged during
  neighbor discovery?
• The practicality of obtaining SRG information
• Resource metrics for OSPF
• Distributed vs centralized path computation
• Interdomain routing with resource constraints

25
Multi-protocol Lambda Switching

• Each OXC is considered the equivalent of an MPLS
  Label-Switching Router (LSR). An IP control
  channel must exist between neighboring OXCs
• MPLS control plane is implemented in each OXC
• The establishment of a lightpath from an ingress
  to an egress OXC requires the configuration of
  the cross-connect fabric in each OXC such that an
  input port is linked to an output port
• MP?S signaling allows an OXC to convey to the
  next OXC in the route the selected output port
  (label)

O1
O2
Request (label) Response (P1)
Request (label) Response (P4)
O5
O4
O3
26
Generalized MPLS

• GMPLS is based on the premise that MPLS can be
  used as the control plane for different switching
  applications
• TDM where time slots are labels (e.g., SONET)
• FDM where frequencies (or ?s) are labels (e.g.,
  WDM)
• Space-division multiplexing where ports are
  labels (e.g., OXCs)
• Generalized labels used in MPLS messaging

Request
Resv/Request
Resv/Request
(OXC example)
Allocate/Port43
Allocate/Port 5
Allocate/Port 21
(OXC with built-in WDM)
Allocate/Fiber 21, ? 8
Allocate/Fiber 5 ? 18
Allocate/Fiber43 ? 9
27
Generalized Label

• Used in place of traditional labels in MPLS
  signaling messages
• May contain a Link ID in addition to the label
  value
• Link ID used when a single control channel is
  used to control multiple data channels
• Label format depends on the link type. Presently
  label formats have been defined for SONET/SDH,
  port, ?, waveband and generic

28
GMPLS Actions

• Generalized Label Request
• Indicates the type of label being requested
• Generalized Label
• Response to label request. Format depends on the
  type of label
• Label Suggestion
• Sent along with label request, to aid in certain
  optimizations
• Label Set
• Sent along with label request. Constrains the
  allocation of labels to those in the set to
  support OXCs without wavelength conversion
  capability

29
Signaling Requirements Bi-directional Lightpaths

• Why not use two unidirectional paths?
• Signaling twice is expensive
• SONET requires the forward and backward paths to
  be on the same circuit pack
• Who owns the label space?
• Avoid label assignment collision
• Resolve collision after in happens

F
L1
D
B
C
A
E
L2
30
Signaling Requirements Fault-Tolerance

• Lightpaths must not be deleted due to failures in
  the control plane
• Present RSVP/CR-LDP mechanisms associate the
  control path with data paths
• Failure in the control path is assumed to affect
  the data path
• Data path is therefore deleted or rerouted
• In optical networks, the fabric cross-connects
  must remain if control path is affected
• Enhancements to RSVP/CR-LDP needed for this.

31
Dynamic Provisioning Across the NNI

• Lightpath request is routed inside source
  sub-network to border OXC (D) based on
  destination address and local routing scheme
• D routes request to border OXC K in dest.
  sub-network (NNI signaling)
• K routes request to destination, N based on
  destination address
• Response routed along the reverse path

Req
C
L
Req
B
M
Req
Req
Req
Req
Resp
Resp
NNI Path Request
Resp
Resp
Resp
Resp
A
D
N
K
NNI Path Resp
F
E
32
Some Issues to Consider

• Service definition and GMPLS semantics for
  different layer technologies
• Optimization of optical layer signaling

33
Restoration

• Objectives
• Low restoration latency
• High restoration capacity efficiency by sharing
  capacity among the backup paths
• High degree of robustness of the restoration
  protocols and the related algorithms
• Scope
• Fast and guaranteed restoration of lightpaths
  after single failure events
• Best-effort restoration after multiple concurrent
  failures

34
Supported Classes of Service

• 11 path protected
• Each primary path is protected by a dedicated
  backup path
• No signaling is necessary during switching from
  the primary path to the backup path
• Mesh restorable
• Each primary path is protected by a shared backup
  path
• Restoration signaling is necessary during
  switching from the primary to the backup path

35
Restoration Protocol Components

• Primary and backup path setup
• Path computation from OSPF generated link state
  database
• Path setup using RSVP-TE/CR-LDP signaling
  protocol
• May be done through the Wavelength Management
  System (WMS)
• Link-level restoration protocol
• Using SONET bit-oriented signaling at the
  link-level
• Path-level restoration protocol
• Using SONET bit-oriented signaling at the
  end-to-end path level

36
Link-Level Restoration Overview
Original Channel Pair
B
C
D
7
4
3
10
7
5
7
7
5
4
E
A
12
14
1
9
New Channel Pair
Drop port
Drop port

• A lightpaths is locally restored by selecting an
  available pair of channels within the same link
• If no channel is available then the end-to-end
  restoration is invoked

37
End-to-End Restoration Overview
Shared Backup Path
H
G
F
8
7
9
4
8
5
Primary Path
B
C
D
7
4
3
10
7
5
7
7
5
4
E
A
12
14
1
9
Local Restoration Failure
Drop port
Drop port

• A shared backup path is soft-setup for each
  restorable primary path
• When local restoration fails, triggers are sent
  to the end-nodes
• End-to-end signaling over the backup path
  activates it and completes end-to-end restoration

38
Optical Control Plane Restoration

• Multi-domain restoration
• Allow possibility of proprietary restoration in
  each sub-network
• Specify an overall end-to-end restoration
  scheme as backup.
• Signaling and routing for end-to-end
  restoration

39
Issues to Consider

• IP-based restoration protocol
• Protocol must satisfy time constraints
• Should a new fast protocol be developed?
• Inter-domain restoration
• Is there a need for end-to-end restoration across
  domains?
• Can this need be satisfied by domain-local
  restoration plus re-provisioning as a fall-back?
• Restoration time requirements

40
IP-Optical Internetworking
41
IP over Optical Service Models Domain Services
Model

• Optical network provides well-defined services
  (e.g., lightpath set-up)
• IP-optical interface is defined by actions for
  service invocation
• IP and optical domains operate independently
  need not have any routing information exchange
  across the interface
• Lightpaths may be treated as point-to-point links
  at the IP layer after set-up

Router Network
Router Network
Optical Cloud
Physical connectivity
Service Invocation Interface
42
Optical Network Services

• Discrete capacity, high-bandwidth connectivity
  (lightpaths)
• Lightpath Creation, Deletion, Modification,
  Status Enquiry
• Directory Services
• Determine client devices of interest
• Supporting Mechanisms
• Neighbor discovery
• Service discovery

43
UNI Abstract Messages

• Lightpath Create Request - UNI-C ? UNI-N
• Lightpath Create Response - UNI-N ? UNI-C
• Lightpath Delete Request - UNI-C ? UNI-N
• Lightpath Delete Response - UNI-N ? UNI-C
• Lightpath Modify Request - UNI-C ? UNI-N
• Lightpath Modify Response - UNI-N ? UNI-C
• Lightpath Status Enquiry - UNI-C ? UNI-N
• Lightpath Status Response - UNI-N ? UNI-C
• Notification - UNI-N ? UNI-C

Concrete realization based on MP?S signaling
constructs
44
Signaling Example
UNI-C (Terminating)
UNI-C (Initiating)
UNI-C (Terminating)
UNI-C (Initiating)
Lightpath Create Request
Lightpath Create Request
Optical Network
2
1
3
4
Lightpath Create Response
Lightpath Create Response
45
UNI Parameters

• Identification-related
• Service-related
• Routing-related
• Security-related
• Administrative
• Miscellaneous

46
Service Models Unified Service Model

• No distinction between UNI, NNI and router-router
  (MPLS) control planeServices are not
  specifically defined at IP-optical interface, but
  folded into end-to-end MPLS services. Routers
  may control end-to-end path using TE-extended
  routing protocols deployed in IP and optical
  networks.Decision about lightpath set-up,
  end-point selection, etc similar in both models.

Router Network
Router Network
Optical Network
47
IP over Optical Services Evolution Scenario

• First phase Domain services model realized using
  appropriate MP?S signaling constructs

Optical Cloud (with or w/o internal MP?S
capability)
Router Network
Router Network
MP?S-based signaling for service invocation, No
routing exchange
48
Evolution Scenario

• Second phase Enhanced MP?S signaling constructs
  for greater path control outside of the optical
  network.
• Abstracted routing information exchange between
  optical and IP domains.

Optical Cloud (with internal MP?S capability)
Router Network
Router Network
MP?S-based signaling for service invocation
(enhanced). Abstracted routing information
exchange
49
Evolution Scenario

• Third Phase Peer organization with the full set
  of MP?S mechanisms.

Optical Cloud (with internal MP?S capability)
Router Network
Router Network
MP?S-based signaling for end-to-end path
set-up. MP?S-based signaling within IP and
optical networks. Full routing information
exchange.
50
Routing for Interworking BGP

• Client network sites belong to a VPN. Client
  border devices and border OXCs run E-BGP. Routing
  in optical and client networks can be different
• Address prefixes in each site (along with VPN id)
  are advertised by border devices to optical
  network.
• Optical network passes these addresses to border
  devices in other sites of the same VPN (along
  with egress OXC address)

O2
O1
R2
R1
R5
R6
O3
x.y.a., x.y.b.
a.b.c.
R4
x.y.c.
R3
O5
O4
Network N3
Network N1
Network N2
51
Issues to Consider

• Which service model?
• Determines complexity of signaling at the
  IP-optical interface
• What are the service requirements on routing and
  signaling?

52
Traffic Engineering
53
IP-over-Optical TE Example Peer Model
Optical network links are OC-48 (2.5 Gbps)
Sequence 1. 100 Mbps LSP from R3 to R8 2. 300
Mbps LSP from R1 to R6 3. 200 Mbps LSP from R2
to R12
54
TE Example Cont.
To set up LSP1 1. R3 computes path
R3-R2-O12-R7-R8 2. R2 establishes an OC-48 FA to
R7 3. LSP occupies 100 Mbps on the FA 4. Links
R2-O12, R7-O12 must be removed from database
when FA R2-R7 is advertised.
55
TE Example Cont.
To set up LSP2 (R1-R6) 1. Path
R1-R2-O11-O13-O14-R4-R6 2. R2 establishes an
OC-48 FA to R4 3. LSP occupies 300 Mbps on the
FA 4. Link R2-OC11 removed from database
Optical Network
O14
O10
O13
R10
R11
O11
O12
O15
R12
R9
R2
R1
R7
FA, 2.5G
R8
R4
R5
R3
R6
56
TE Example Cont.
To set up LSP3 (R2-R12) 1. Path
R2-R7-R9-O15-O14-O13-O10-R10-R12 2. R9
establishes an OC-48 FA to R10 3. LSP occupies
200 Mbps on the FA 4. Link R9-O15 R10-O10
removed from database. The next LSP set-up
utilizes an overlay topology of FAs only! It may
make sense to change this topology based on
observed traffic pattern between routers Thus,
the design of this overlay is an important TE
issue.
R10
R11
R4
R5
R12
R6
R7
R2
R1
R9
R8
R3
57
Topology Design

• General objective
• Design topology of least cost that accommodates
  traffic demand
• When LSPs are routed over an FA topology
• Routers may have to optimize overlay topology to
  utilize available resources (ports, etc)
  efficiently and minimize cost
• Co-ordination among routers may be required for
  this
• Internally, some optimizations are possible in
  the optical network to minimize capacity usage,
  based on overall view of lightpaths routed. It is
  difficult to push this functionality outside of
  the optical network

58
IP-over-Optical TE Example Domain Model
1. Each border router gets reachability of
others 2. Each border router keeps track of
availability of edge links 3. Lightpaths are set
up internally in optical network 4. Overlay
virtual link (VL) topology is formed based on
LSP demand between router networks.
59
TE Example - Domain Model
To set up LSP1 1. R3 computes path
R3-R2-ltunspecifiedgt-R8 2. R2 sends a request to
optical net to set-up a path to R7 3. Lightpath
is established from R2 to R7 4. LSP occupies 100
Mbps on the virtual link 5. The VL is also a
new routing adjacency
Router Network
Optical Network
R5
R4
O14
O10
Router Network
O13
R10
R11
R6
O11
O12
O15
R12
R9
R7
FA, 2.5G
R2
R1
R8
Router Network
R3
Router Network
60
IP-over-Optical TE Issues

• TE rules should be incorporated in all routers to
  decide when to select new optical paths, as
  opposed to using existing FAs or VLs
• Should resource optimization in optical network
  be an objective of LSP routing? (This requirement
  may be handled best internally in the optical
  network)
• TE work must investigate to what degree internal
  optical network information (topology, etc) aid
  in IP over optical TE decisions.
• Specifically, with regard to protection,
  requiring physical topology characteristics (e.g.
  SRLG) of optical network at the IP layer for
  computing alternate paths may be impractical.

61
Finally.

• What applications may be built based on dynamic
  bandwidth provisioning?