IP over Optical Networks - A Framework

draft-ip-optical-framework-01.txt
Bala Rajagopalan
James Luciani
Daniel Awduche
Brad Cain
Bilel Jamoussi

IETF 7/31/00

About this Draft

Deals with the following issues:
IP transport over optical networks
IP-centric control plane for optical networks (MP?S-based)
Defines terminology
Describes the optical network model
Describes service models
Describes architectural alternatives
Defines requirements
Proposes an evolution path for IP over Optical capabilities

IETF 7/31/00

Outline

Network and service models

IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
IP-centric control plane issues
Conclusion

IETF 7/31/00

Outline
Network and service models
Network Model
Domain Services Model
Unified Services Model
IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
IP-centric control plane issues
Conclusion

IETF 7/31/00

IP over Optical: Model

Other Network

Optical Network
Optical
Subnet

Router Network

IF2
IF1

Optical
Subnet

Optical
Subnet
Optical Path
End-to-end path (LSP)

IETF 7/31/00

Router Network

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

Service Invocation Interface

6

IETF 7/31/00

Physical connectivity

Domain Services Model: Lightpath Set-Up

1.
2.
4.
6.

Decision to establish lightpath (e.g., offline TE computations)

Request lightpath set-up. 3. Internal optical network signaling
Lightpath set-up requested at destination 5. Lightpath set-up accepted
Internal optical network signaling 7. Successful lightpath set-up

Router Network

Router Network
2

Optical Cloud
7

1
7

IETF 7/31/00

Service Models: Unified Service Model

IP and optical network treated as a single integrated network for control purposes
No distinction between IF1, IF2 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

IETF 7/31/00

Unified Service Model: End-to-End Path Set-Up

1. Trigger for path set-up (e.g., TE decision)
2. End-to-end path computation (may use previously declared Fas, or visibility
into optical network topology)
3. Forward signaling for path set-up
4. Reverse signaling for path set-up
4
3
2

IETF 7/31/00

Outline

10

Network and service models

IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
IP-centric control plane issues
Conclusion

IETF 7/31/00

IP over Optical Services Evolution Scenario

Definition of capability sets that evolve
First phase: Domain services model realized using appropriate MP?S signaling
constructs

Router Network

Router Network
Optical Cloud
(with or w/o
internal MP?S
capability)

MP?S-based signaling for

service invocation, No routing exchange
11

IETF 7/31/00

Evolution Scenario (contd.)

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.
Router Network

Router Network
Optical Cloud
(with
internal MP?S
capability)

MP?S-based signaling for

service invocation (enhanced). Abstracted
routing information exchange
12

IETF 7/31/00

Evolution Scenario (Contd.)

Phase 3: Peer organization with the full set of MP?S mechanisms.
Optical 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.

13

IETF 7/31/00

Outline

14

Network and service models

IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
IP-centric control plane issues
Conclusion

IETF 7/31/00

The Role of MP?S

This framework assumes that MP?S will be the basis for supporting different
IP over optical service models
Main expectations:
Define signaling and routing mechanisms for accommodating IP over
optical network service models
Define representations for addressable entities and service attributes
Realize above within the framework of requirements for different service
models
Define a clear set of mechanisms for each set of (increasingly sophisticated)
capabilities required
Accommodate an evolution path for service capabilities

15

IETF 7/31/00

Outline

Network and service models

IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
Architectural alternatives
Routing approaches
IP-centric control plane issues
Conclusion

16

IETF 7/31/00

IP over Optical Networks: Architectural Models

Architectural alternatives defined by control plane organization
Overlay model (loosely coupled control planes)
Augmented model (loosely coupled control planes)
Peer model (tightly coupled control planes)
Routing approaches
Integrated routing (peer model)
Domain-specific routing (augmented model)
Overlay routing (overlay model)

17

IETF 7/31/00

Integrated Routing: OSPF

Entire client-optical network treated as single network. Both client and optical networks
run same version of OSPF protocol
Client devices (routers) have complete visibility into optical network
Clients compute end-to-end path
Client border devices must manage lightpaths (bandwidth allocation, advertisement of
virtual links, etc.)
Determination of how many lightpaths must be established and to what endpoints are
traffic engineering decisions
R1

O1

R5
O2

R2
R3
Network N1

18

R4 ,

O3
Network N3
Network N2
IETF 7/31/00

Domain-Specific Routing: BGP

Client network sites belong to a VPON. Client border devices and border
OXCs run E-BGP. Routing in optical and client networks can be different
BGP/MPLS VPN model defined in draft-rosen-rfc2547bis-02.txt may be
applied
Determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions
IBGP
R1
x.y.c.*

EBGP

O1

EBGP
O2

R4 x.y.a.*,
x.y.b.*

R2
R3

R5

O3 a.b.c.*
Network N3

Network N1

19

Network N2
IETF 7/31/00

Overlay Routing

Each client border router registers its address (and VPON id) with the optical network
Optical network allows other client border routers belonging to the same VPON to
query for addresses.
IP routers establish lightpaths and run a routing protocol on the overlay topology
Determination of how many lightpaths must be established and to what endpoints are
traffic engineering decisions
Registration Message

Registration Service
<a.b.c.1, 1>
<x.y.z.1, 1>
R1
a.b.c.1 <a.b.c.1, 1>
R2
R3
VPON 1

20

O3
<x.y.z.1, 1>

Reachability Message

<a.b.c.1, 1>
<x.y.z.1, 1>
<a.b.c.1, 1>

O
2

R5
<x.y.z.1, 1> R4 x.y.z.1

IETF 7/31/00

VPON 1

Outline

21

Network and service models

IP over Optical network services evolution
The role of MP?S
IP over Optical network architectures
IP-centric control plane issues
Conclusion

IETF 7/31/00

IP-centric Control Plane: Main Issues

Control procedures within and between sub-networks
distinguished.
MP?S control plane is assumed. Issues considered:
Identification
Neighbor discovery
Topology discovery
Restoration models
Route computation
Signaling issues
Optical internetworking

22

IETF 7/31/00

are

Identification
Termination point identification in optical networks
Possible structure: Node, Port, Channel, Sub-channel
Trail segment identification between adjacent OXCs
MP?S labels with the required structure (e.g., port, channel, subchannel)
SRLG Identifiers: Flat identifiers?

23

IETF 7/31/00

Neighbor Discovery
To determine the local link connectivity between adjacent OXCs
Serves as the first step towards topology discovery
Required for specifying MP?S labels over optical links
Neighbor discovery over opaque and transparent links
Procedures TBD
LMP is referred as a possibility

24

IETF 7/31/00

Topology Discovery
Link state protocol recommended
Bundling recommended to reduce number of adjacencies and links
represented
Bundling structure is TBD.
The encoding of restoration-related parameters for computing shared
protection paths is TBD

25

IETF 7/31/00

Route Computation & Signaling

Route computation with SRLG constraints is discussed
Signaling issues described
Bi-directional lightpaths
Fault-tolerance
Signaling for restoration

26

IETF 7/31/00

Optical Internetworking

Optical
Subnet

Requirements discussed:
Common, global addressing scheme for optical path endpoints
Propagation of reachability information
End-to-end path provisioning using signaling
Policy support (accounting, security, etc)
Support for subnet-proprietary provisioning and restoration algorithms
27

IETF 7/31/00

Optical Control Plane: Restoration

Multi-domain restoration:
Allow possibility of proprietary restoration in each subnetwork
Specify an overall end-to-end restoration scheme as backup.
Signaling and routing for end-to-end restoration
28

IETF 7/31/00

Conclusion
The draft gives a high-level overview of IP over Optical service
models and architectures
Recommends an evolutionary approach to IP over optical, starting
from simple capabilities and going to more sophisticated capabilities
IP over Optical requirements not yet defined in the framework
Domain services model requirements available
Restoration issues require further discussion
IP over optical traffic engineering issues need coverage

29

IETF 7/31/00