IP over Optical Networks - PowerPoint PPT Presentation

Loading...

PPT – IP over Optical Networks PowerPoint presentation | free to download - id: 731f4c-ZDRlN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

IP over Optical Networks

Description:

IP over Optical Networks Debanjan Saha Bala Rajagopalan {dsaha, braja}_at_tellium.com – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 62
Provided by: dsa100
Learn more at: http://www.nanog.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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-networks I-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 plane Services 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?
About PowerShow.com