IP over Optical Networks - A Framework - - PowerPoint PPT Presentation

1 IETF 7/31/00

IP over Optical Networks - A Framework

draft-ip-optical-framework-01.txt

Bala Rajagopalan James Luciani Daniel Awduche Brad Cain Bilel Jamoussi

2 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

3 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

4 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

5 IETF 7/31/00

IP over Optical: Model

Optical Subnet Optical Subnet Optical Subnet Router Network Other Network Router Network

Optical Network

End-to-end path (LSP) Optical Path IF1 IF2

6 IETF 7/31/00

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

Optical Cloud Router Network Router Network Service Invocation Interface Physical connectivity

7 IETF 7/31/00

Domain Services Model: Lightpath Set-Up

• 1. Decision to establish lightpath (e.g., offline TE computations)
• 2. Request lightpath set-up. 3. Internal optical network signaling
• 4. Lightpath set-up requested at destination 5. Lightpath set-up accepted
• 6. Internal optical network signaling 7. Successful lightpath set-up

Optical Cloud Router Network Router Network 1 2 3 4 5 6 7

8 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

9 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

1 3 4 2

10 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

11 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

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

12 IETF 7/31/00

Evolution Scenario (contd.)

• Second phase: Enhanced MP?S signaling constructs for greater path control
• utside 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

13 IETF 7/31/00

Evolution Scenario (Contd.)

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

MP?S-based signaling for end-to-end path set-up. MP?S-based signaling within IP and optical networks. Full routing information exchange. Optical network Router network

14 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

15 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

• ptical 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

16 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

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

18 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 R2 R3 R4 R5 O1 O2 O3 , Network N1 Network N2 Network N3

19 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

R1 R2 R3 R4 R5 O1 O2 O3 x.y.a.*, x.y.b.* a.b.c.* x.y.c.* Network N1 Network N2 Network N3

EBGP EBGP IBGP

20 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

R1 R2 R3 O 2 O3 R4 R5 VPON 1 VPON 1 x.y.z.1 a.b.c.1 Registration Message Reachability Message <x.y.z.1, 1> <a.b.c.1, 1> <a.b.c.1, 1> <x.y.z.1, 1> <x.y.z.1, 1> <a.b.c.1, 1>

Registration Service

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

21 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

22 IETF 7/31/00

IP-centric Control Plane: Main Issues

• Control

procedures within and between sub-networks are distinguished.

• MP?S control plane is assumed. Issues considered:

– Identification – Neighbor discovery – Topology discovery – Restoration models – Route computation – Signaling issues – Optical internetworking

23 IETF 7/31/00

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, sub- channel)

• SRLG Identifiers: Flat identifiers?

24 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

25 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

26 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

27 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

28 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

29 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