Advanced IP-Centric Control of Optical Networks: Enhancing Efficiency and Flexibility

1. IP over Optical Networks Debanjan Saha Bala Rajagopalan {dsaha, braja}@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/3’s 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 - Requestl Step 3 - Releasel Step 2 - OXC Provides l • 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 Optical Subnet Router Network Optical Subnet Router Network

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. Optical subnet Optical subnet Optical Subnet 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 Optical Network Router Network UNI NDP SRG #2 SRG #3 O5 NDP NDP NDP NDP Optical Network SRG #4 Router Network SRG #5 UNI NDP NDP O4 O3 SRG #6

15. Type Resource Class Status ID Speed SROG Remote Node Remote Port 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 123 Up OC-192 F123, C231 2 Network 8.4.1.3 11.3.1.3 Primary 345 Network SF OC-48 F234, C251 1023 Primary 129.2.1.3 15 Up OC-48 Network 1024 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 Resource sub-bundle# 1 O1 O2 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 2 Sub-network 1 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/Port=43 Allocate/Port= 21 Allocate/Port= 5 (OXC with built-in WDM) Allocate/Fiber= 21,  = 8 Allocate/Fiber= 5  = 18 Allocate/Fiber=43  = 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 C B 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 M B 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 • 1+1 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 • 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 7 4 5 4 7 3 10 7 5 7 E A 12 14 1 9 New Channel Pair Drop port Drop port

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

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