IP over Optical Networks - A Framework draft-ip-optical-framework-01.txt

Transcription

1 IP over Optical Networks - A Framework draft-ip-optical-framework-01.txt Bala Rajagopalan James Luciani Daniel Awduche Brad Cain Bilel Jamoussi 1 IETF 7/31/00

2 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 2 IETF 7/31/00

3 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 3 IETF 7/31/00

4 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 4 IETF 7/31/00

5 IP over Optical: Model Router Network Optical Network Optical Subnet Other Network IF2 IF1 Optical Subnet Optical Path Optical Subnet Router Network End-to-end path (LSP) 5 IETF 7/31/00

6 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 Physical connectivity 6 IETF 7/31/00

7 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 Router Network 2 3 Optical Cloud 4 Router Network IETF 7/31/00

8 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 8 IETF 7/31/00

9 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 IETF 7/31/00

11 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 Optical Cloud (with or w/o internal MP?S capability) Router Network MP?S-based signaling for service invocation, No routing exchange 11 IETF 7/31/00

12 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 Optical Cloud (with internal MP?S capability) Router Network MP?S-based signaling for service invocation (enhanced). Abstracted routing information exchange 12 IETF 7/31/00

13 Evolution Scenario (Contd.) Phase 3: Peer organization with the full set of MP?S mechanisms. Router network Optical 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

15 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

16 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

17 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

18 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 Network N1 O1 O2 O3 Network N2 R5 R4, Network N3 18 IETF 7/31/00

19 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.* R2 R3 Network N1 EBGP O1 O2 O3 a.b.c.* Network N2 EBGP R4 R5 x.y.a.*, x.y.b.* Network N3 19 IETF 7/31/00

20 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 Reachability Message <a.b.c.1, 1> <x.y.z.1, 1> <a.b.c.1, 1> <x.y.z.1, 1> VPON 1 R2 R1 a.b.c.1 R3 <a.b.c.1, 1> O3 <x.y.z.1, 1> O 2 <a.b.c.1, 1> <x.y.z.1, 1> R4 R5 x.y.z.1 VPON 1 20 IETF 7/31/00

22 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 22 IETF 7/31/00

23 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

24 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

25 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

26 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

27 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

28 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

29 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