Internet 2 Network Tutorial Control Plane and Dynamic

Internet 2 Network Tutorial: Control Plane and Dynamic Services Rick Summerhill, Matt Zekauskas, Russ Hobby Internet 2 Joint Techs University of Minnesota 11 February 2007 Minneapolis, MN

Control Plane Deployment • Collaborations with Other Networks • High Level Overview: • What are we trying to do? • Review of Higher Level Objectives • HOPI Testbed Overview • Deployment on the Internet 2 Network • The DRAGON GMPLS Control Plane

Collaboration with Other Networks • Working closely with Dante, Canarie, and ESnet on Inter-domain Interoperability • Meetings in December and January, to continue in May • Much ongoing work to utilize existing technologies • Will meet in May after TERENA 2007 • Also participating in the OGF working groups to insure standards compatibility • For example, integrate existing topology disccovery efforts

Overview • Support Applications that demand capabilities that are hard to support in a shared packet infrastructure • Large bandwidth applications • Applications that benefit from circuit characteristics, and that may be low bandwidth in nature • Dynamically create data paths that look like circuits, often called ”lightpaths” • Russ Hobby will talk more about this • Networks taking different approaches: • • ESnet is taking an MPLS over Ethernet approach Internet 2 (HOPI) taking an Ethernet VLAN approach Internet 2 (Ciena) taking a SONET approach GEANT is taking a SONET approach

HOPI Testbed Overview • Nodes located in 5 major cities on the Internet 2 DWDM platform • Dynamically create VLANS across the infrastructure • Completely independent of the DWDM infrasturcture • Likely to become more experimental as services are migrated to the Internet 2 Network • Discussions about a completely new approach at this meeting • Overview of Control Plane Ideas:

Development Team for DCS • Team created to bring dynamic services to the Internet 2 Network using the Ciena Platform • • • Tom Lehman - lead Jerry Sobieski Xi Yang Chris Tracy Jarda Flidr Additional developer to be named later • Develop services over the next two years incorporating the entire network • Workshops in preparation, more later

Overview of Basic Control Plane Ideas • Intra-domain • Inter-domain • Basic Ideas: • Topology • Path Computation • Signaling • Additional components • Scheduling • AAA

Client “Service” View Service Request User Identification (certificate) Source Address Destination Address Bandwidth (50 Mbps increments) VLAN TAG (None | Any | Number) Schedule CSA can run on the client or in a separate machine (proxy mode) Dynamically Provisioned Dedicated Resource Path (“Circuit”) Domain Controller b 1 2 CSA Client A a Ethernet Mapped SONET or SONET Circuits Internet 2 DCS CSA Client B

Intra-Domain Service Request VLSR User Identification (certificate) Source Address Destination Address Bandwidth (50 Mbps increments) VLAN TAG (None | Any | Number) Schedule Domain Controller 1 b 2 CSA Switch Fabric CSA a Client B Client A Internet 2 DCS Ethernet Mapped SONET or SONET Circuits

Inter-Domain Controller CSA RON Dynamic Infrastructure Ethernet VLAN Internet 2 DCS Ethernet Mapped SONET

DRAGON Control Plane Status and Adaptation to Internet 2 Network Slides by Tom Lehman University of Southern California Information Sciences Institute (USC ISI) And Others from the Development Team

Topics DRAGON Control Plane Status l Thoughts/Considerations regarding Evolution to Internet 2 Control Plane l Advanced Topics: Web Services, AAA, Scheduling l Next Steps and Timelines l

DRAGON Control Plane Key Components l Network Aware Resource Broker – NARB l l Virtual Label Swapping Router – VLSR l l l Open source protocols running on PC act as GMPLS network element (OSPF-TE, RSVP-TE) Control PCs participate in protocol exchanges and provisions covered switch according to protocol events (PATH setup, PATH tear down, state query, etc) Client System Agent – CSA l l Intradomain listener, Path Computation, Interdomain Routing End system or client software for signaling into network (UNI or peer mode) Application Specific Topology Builder – ASTB l l User Interface and processing which build topologies on behalf of users Topologies are a user specific configuration of multiple LSPs

Multi-Domain Control Plane The (near-term) big picture l l l Multi-Domain Provisioning Interdomain ENNI (Web Service and OIF/GMPLS) Multi-domain, multi-stage path computation process AAA Scheduling Internet 2 Network RON Dynamic Ethernet Domain Controller Ctrl Element Ethernet SONET Switch Router TDM GEANT RON Dynamic Ethernet ESNet Data Plane Control Plane Adjacency LSP IP Network (MPLS, L 2 VPN)

DRAGON/HOPI Control Plane Provisioning Environment GMPLS Multi-layer, Multi-Domain Ethernet Service Provisioning Dynamic dedicated VLAN based connections l l l IGP-TE GMPLS Provisioned LSP Dedicated Ethernet VLAN “Circuit” UNI SEA LA CHI Ethernet Layer NY HOU GWU DC MCLN ARLG UNI CLPK DCNE Switched WDM Optical Layer Static Optical Layer HOPI Dynamic Ethernet Network Ethernet Layer ENNI Domain Boundary DRAGON Multi-Layer GMPLS Network

Heterogeneous Network Technologies Complex End to End Paths “horizontal” multi-layer adaptations for multi-domain AS 2 AS 1 IP Control Plane AS 3 IP Control Plane VLSR Ethernet over WDM End System Ethernet Segment VLSR Established VLAN Ethernet over SONET Ethernet Lambda Switch SONET Switch Router MPLS LSP End System Ethernet Segment VLSR Established VLAN

DRAGON Control Plane Interoperation with Ciena Domain l Three Options l l GMPLS l l l One VLSR per Core Director; front end for signaling Handles AAA, any special purpose configuration not handled by current GMPLS protocols (edge VLAN mapping adjustment for instance), other unique processing associated with peer entities GMPLS Wrapper over Management Plane l l All have one NARB per Ciena Domain, receives topology information from Ciena Domain (ENNI, CORBA, static configuration ? ) One VLSR per Core Director Domain Presents GMPLS to the outside world (probably as single opaque network with multiple external connections) Use CORBA for Core Director Provisioning GMPLS Wrapper over Management Plane (Option 2) l Same as above but use a “management style” system which talks to Ciena Domain via UNI or ENNI

Ongoing Ciena Testing l l l Resource Partitioning. Can resources be partitioned such that control plane (OSRP) provisioned resources and manually (management system) can be isolated from each other? We believe this is possible Is it possible to police VLANS? Can each VLAN be policed and rate limited independently? We believe this is also possible! Looking forward to UNI 2. 0 and ENNI availability VCAT/LCAS interoperability with other vendors? Will GFP encapsulated ethernet frames be interoperable with other vendors?

VLSR (Virtual Label Switching Router) l l GMPLS Proxy l (OSPF-TE, RSVP-TE) Local control channel l CLI, TL 1, SNMP, others Used primarily for ethernet switches Provisioning requests via CLI, XML, or ASTB Web page XML Interface CLI Interface ASTB One NARB per Domain

VLSR (Virtual Label Switching Router) l RSVP Signaling module l l l l OSPF Routing module l l Originated from Martin Karsten’s C++ KOM-RSVP Extended to support RSVP-TE (RFC 3209) Extended to support GMPLS (RFC 3473) Extended to support Q-Bridge MIB (RFC 2674) For manipulation of VLANs via SNMP (cross-connect) Extended to support VLAN control through CLI Originated from GNU Zebra Extended to support OSPF-TE (RFC 3630) Extended to support GMPLS (RFC 4203) Ethernet switches tested to date l Dell Power. Connect, Extreme, Intel, Raptor, Force 10

NARB Network Aware Resource Broker l Interdomain Routing l l Carries a modified TEDB that can support l l l hierarchical link state AAA Scheduling Path Computation Element and ERO (loose and strict) generation Inter. Domain Exchange NARB End System AS 1 AS 2 AS 3

NARB (Network Aware Resource Broker) l l NARB is an agent that represents a domain Intra-domain Listener l l l Inter-domain routing l l Peers with NARBs in adjacent domains Exchanges (abstracted) topology information Maintains an inter-domain link state database Path Computation l l Listens to OSPF-TE to acquire intra-domain topology Builds an abstracted view of internal domain topology Performs intra-domain (strict hop) TE path computation Performs inter-domain (loose hop) TE path computation Expands loose hop specified paths as requested by domain boundary (V)LSRs. Hooks for incorporation of AAA and scheduling into path computation via a “ 3 Dimensional Resource Computation Engine (3 D RCE)” l l l The Traffic Engineering Data. Base (TEDB) and Constrained Shortest Path Computation (CSPF) are extended to include dimensions of GMPLS TE parameters, AAA constraints, and Scheduling constraints. 3 D RCE is the combination of 3 D TEDB and 3 D CSPF http: //dragon. east. isi. edu/data/dragon/documents/dragon-infocom-APBMworkshop-apr 282006. pdf

What is the HOPI Service? l Physical Connection: l l Circuit Service: l l Point to Point Ethernet VLAN Circuit Tagged or Untagged VLANs available Bandwidth provisioning available in 100 Mbps increments How do Clients Request? l l 1 or 10 Gigabit Ethernet Client must specify [VLAN ID|ANY ID|Untagged], SRC Address, DST Address, Bandwidth Request mechanism options are GMPLS Peer Mode, GMPLS UNI Mode, Web Services, phone call, email Application Specific Topology is a user specific instantiation of multiple individual circuits What is the definition of a Client? l Anyone who connects to an ethernet port on an HOPI Force 10 Switch; could be RONS, GIga. Pops, other wide area networks, end systems

GMPLS Provisioned Ethernet Services “Local ID” for Egress Control VLSR PC Ethernet switch l l l l User Requests: VLSR PC VLAN XX LSP Ethernet switch VLAN YY LSP VLSR PC Ethernet switch • Peer to Peer • UNI • XML API VLSR PC Ethernet switch Multiple Ethernet Provisioning Options Point to Point Ethernet VLAN based LSPs Ethernet switch (vendor specific) features applied to guarantee LSP bandwidth in increments of 100 Mbit/s Edge connection flexibility provided by use of “Local ID” feature which allows flexible combinations of one port, multiple ports, tagged ports, and untagged ports to be glued on to end of LSP. Can be dynamically adjusted. Users can request services via Peer to Peer GMPLS, UNI style GMPLS, or via an XML application interface Ethernet VLAN space is “flat” across provisioned space. Constrained based path computation utilized to find available VLAN Tags. VLAN tags treated in a similar manner to wavelengths

Ethernet VLAN based Provisioning l Local ID defines the VLAN tag/edge port mapping l l l OSPF l l l proprietary Unnumbered Interface ID Subobjects (Un. Num. If. ID) used to encode VLAN information in ERO 32 -bit Un. Numbered Interface ID: type(1 byte): value(24 bits, vlan tag info) NARB/RCE l l configure vlans on each interface advertise out in If. Sw. Cap Descriptor TLV inside a TE Link LSA update vlans availability and bandwidth in response to provisioning similar to the existing ifswcap-specific-psc and ifswcap-specific-tdm RSVP ERO l l Several options; tagged, untagged, single port, port groups, automatic Local ID definitions can be adjusted dynamically listen to OSPF path computation with bandwidth and vlan constraints create EROs with Un. Num. IFID objects Driven by need to provision across HOPI (10 gigabit interfaces)

DRAGON Provisioning Web Page Interface

Application Specific Topologies using XML C A e. VLBI. Mark 5 a Haystack. muk 1 muk 1. haystack. mit. edu muk 1 -ge 0. haystack. mit. edu /usr/local/evlbi_script e. VLBI. Mark 5 a Westford 1 wstf. haystack. mit. edu wstf-ge 0. haystack. mit. edu /usr/local/evlbi_script Ether. Pipe. Basic Haystack. muk 1 Westford. muk 1 1 Gbs B A B C

Application Specific Topologies l l Live demonstration at Internet 2 Spring Member Meeting (April 2006, Washington DC) l See www. internet 2. edu for webcast of “HOPI update” presentation. Set up global multi-link topologies l ~30 seconds

Internet 2 Network: Infrastructure with Multiple Services “ Routed IP Network” Router Layer Ethernet Layer Switched SONET Layer (vcat, lcas) Provisioned Topologies Switched WDM Optical Layer Ethernet Layer Switched SONET Layer (vcat, lcas) “SONET Switched Network” “Ethernet VLAN Switched Network (i. e. , HOPI)” Switched WDM Optical Layer Multi-Layer GMPLS Networks Separate (Peering) Control Plane Instantiations for each of the above

Dynamic Circuit Service l Physical Connection: l l l Circuit Service: l l l Point to Point Ethernet VLAN Circuit Point to Point Ethernet Framed SONET Circuit Point to Point SONET Circuit Bandwidth provisioning available in 50 Mbps increments (STS-1 granularity) How do Clients Request? l l 1 or 10 Gigabit Ethernet OC-3, OC-12, OC-48, OC 192 SONET Client must specify [VLAN ID|ANY ID|Untagged], SRC Address, DST Address, Bandwidth Request mechanism options are GMPLS Peer Mode, GMPLS UNI Mode, Web Services, phone call, email Application Specific Topology is a user specific instantiation of multiple individual circuits What is the definition of a Client? l A Device on the network requesting a circuit connection

Control Plane Objectives l Multi-Service, Multi-Domain, Multi-Layer, Multi-Vendor Provisioning l l Basic capability is the provision of a “circuit” in above environment In addition, need control plane features for: l l l AAA Scheduling Easy APIs which combine multiple individual control plane actions into an application specific configuration (i. e. , application specific topologies)

Key Control Plane Features (for Connection Control) l Routing l l Path computation l l distribution of "data" between networks. The data that needs to be distributed includes reachability information, resource usages, etc the processing of information received via routing data to determining how to provision an end-to-end path. This is typically a Constrained Shortest Path First (CSPF) type algorithm for the GMPLS control planes. Web services based exchanges might employ a modified version of this technique or something entirely different. Signaling l the exchange of messages to instantiate specific provisioning requests based upon the above routing and path computation functions. This is typically a RVSP-TE exchange for the GMPLS control planes. Web services based exchanges might employ a modified version of this technique or something entirely different.

Key Control Plane Key Capabilities l Domain Summarization l l Multi-layer “Techniques” l l Ability to generate abstract representations of your domain for making available to others The type and amount of information (constraints) needed to be included in this abstraction requires discussion. Ability to quickly update this representation based on provisioning actions and other changes Stitching: some network elements will need to map one layer into others, i. e. , multi-layer adaptation In this context the layers are: PSC, L 2 SC, TDM, LSC, FSC Hierarchical techniques. Provision a circuit at one layer, then treat it as a resource at another layer. (i. e. , Forward Adjacency concept) Multi-Layer, Multi-Domain Path Computation Algorithms l l Algorithms which allow processing on network graphs with multiple constraints Coordination between per domain Path Computation Elements

Inter-Domain Topology Summarization Full Topology Semi-topo (edge nodes only) Maximum Summarization - User defined summarization level maintains privacy - Summarization impacts optimal path computation but allows the domain to choose (and reserve) an internal path

Integration Core Director Domain into the Endto-End Signaling VLSR uni-subnet uni LSR upstream signaling flow data flow uni LSR downstream Ciena Subnet CD_a subnet signaling flow CD_z • Signaling is performed in contiguous mode. • Single RSVP signaling session (main session) for end-to-end circuit. • Subnet path is created via a separate RSVP-UNI session (subnet session), similar to using SNMP/CLI to create VLAN on an Ethernet switch. • The simplest case: one VLSR covers the whole UNI subnet. • VLSR is both the source and destination UNI clients. • This VLSR is control-plane ‘home VLSR’ for both CD_a and CD_z. • UNI client is implemented as embedded module using KOM-RSVP API.

I 2 DCS Development Lab Control PC (VLSR) Local Network Client System Bloomington routed network Local Network Control PC (VLSR) Client System Indianapolis

An Example of How to Connect to HOPI and the Internet 2 Network - Phase 1 • Campus connects through RON using static VLANs and deploys VLSR on PC connected to switch (GMPLS control plane) • Ethernet based • Connect to HOPI control plane

Phase 2 • Add NARB (could be same PC) • Separates the campus domain from HOPI domain • Now have separate control planes

Phase 3 • When ready, RON implements GMPLS control plane

Phase 4 • Move to the Multiservice Switching Infrastructure on the Internet 2 Network • There are many other possible alternatives

Workshops • Two day workshop • Provide a working knowledge of how to design and deploy a GMPLS based dynamic services network • Overview of GMPLS architecture • RSVP and OSPF protocols • Basic Control Plane Concepts • Routing, Path Computation, Signaling

Workshops, continued • Hands-on workshop, attendees will: • Implement a dynamic services test-bed (Ethernet based), using the DRAGON GMPLS Software Suite • Schedule: • First day will focus on concepts and basic control plane design and implementation • Second day will explore inter-domain dynamic services and provisioning • Target Audience: Senior Network Engineers familiar with current R&E network infrastructure, IP architectures, and ethernet switching. • See http: //add this in

Additional Slides

Interdomain Path Computation A Hierarchical Architecture l l l NARB summarizes individual domain topology and advertises it globally using link-state routing protocol, generating an abstract topology. RCE computes partial paths by combining the abstract global topology and detailed local topology. NARB’s assemble the partial paths into a full path by speaking to one another across domains.

E 2 E Multi-Domain Path Computation Scheme DRAGON mainly uses Recursive Per-Domain (RPD) interdomain path computation l l Full explicit path is obtained before signaling. Other supported schemes include Centralized path computation and Forward Per-Domain (FPD) path computation.

DRAGON CSPF Path Computation Heuristics l A breadth first search based CSPF heuristic in deployment l l Takes flexible combination of various constraints, such as bandwidth, switch cap. , wavelength, VLAN tag and add-on policy constraints. Supports multi-region networks using configurable regioncrossing criteria Reliable results; probably time-consuming in large networks (~30 ms in the 12 -node HOPI+DRAGON network) Other heuristics under research; one is based on a channel-graph model in combination with Kshortest path routing.

Three Policy Dimensions in GMPLS Service Provisioning l Resource dimension l l l AAA policy dimension l l l Link availability, bandwidth capability & resource interdependence TE constraints, e. g. switching cap. User privileges App. specific requirements (SLA) Administration policies Time schedule dimension Integrate and translate network resource states and policies into shared control plane intelligence. Synergize AAA policy decision with TE based provisioning decision, resulting in fast, precise and simplified control process.

3 Dimensional (3 D) Resource Computation Model Resource states, time schedule and AAA policies are exchanged among control-plane entities in both intradomain and interdomain scopes. Three dimensions of constraints are used in joint to compute which resource to allocate and generate policy decisions. GMPLS routing, path computation Actual service provisioning: resource allocation and policy enforcement. GMPLS signaling

DRAGON Resource Computation Engine (RCE) Interdomain E 2 E path computation Support Advance scheduled service provisioning AAA based provisioning and admission control l l RCE is the element in GMPLS control-plane to perform the computation intensive resource management & policy decision tasks. RCE can be used as a standalone server or as an integrated NARB module.

3 D Constraint Based Path Computation Data source (raw link states from intra- and inter-domain flooding) and 3 D constraints Snapshot of topology reduced by policy filters Constraint based path computation algorithm - CSPF heuristics

AAA Based Provisioning l l AAA Policy TE Link TLV Allows a AAA information to be included as part of path computation Path Computation understanding/interpretation of rules very simple Much work needed in this area

Time Based Provisioning Schedule TE Link TLV l Allows a time constraint to be included as part of path computation l

Continuing Work Key Focus Areas l GMPLS Control Plane l Inter-domain routing and signaling agreements l l l l R&E community should make this a priority Advanced path computation techniques Inter-operability with vendor stacks Multi-layer stitching AAA and Scheduling Control Plane Features Web Service based control planes Application Specific Topologies l l Integration/reconciliation of AST, Network Description Language, Common Service Definition specs Integration with applications

Multi-Layer GMPLS Networks “vertical” multi-layer adaptations for traffic grooming, multiple services, multiple “virtual” networks Ethernet Layer Switched WDM Optical Layer Ethernet Layer Switched SONET Layer (vcat, lcas) Switched WDM Optical Layer

The Vision: One Infrastructure Multiple Topologies/Services “ Ethernet Framed Lambda” Ethernet Layer Provisioned Topologies “Basic Ethernet Service” Switched WDM Optical Layer Multi-Layer GMPLS Networks Ethernet Layer Switched SONET Layer (vcat, lcas) Switched WDM Optical Layer “Dedicated VLAN Connection over Ethernet”

Heterogeneous Network Technologies Complex End to End Paths “horizontal” multi-layer adaptations for multi-domain AS 2 AS 1 IP Control Plane AS 3 IP Control Plane VLSR Ethernet over WDM End System Ethernet Segment VLSR Established VLAN Ethernet over SONET Ethernet Lambda Switch SONET Switch Router MPLS LSP End System Ethernet Segment VLSR Established VLAN

Inter. Domain (G)MPLS and Web Services l Currently working on interdomain virtual circuit provisioning between: l l l ESnet Abilene HOPI Ultra. Science Net Focusing on how to accomplish routing, signaling, path computation in a mixed (G)MPLS and Web Service environment

DRAGON Control Plane R&E “Hybrid” Networks l l l l l Multi-Service, Multi-Level, Multi-Domain One “infrastructure” which provides basic IP routed service as well services at lower layer l i. e. , connectionless and connection oriented services Services could be point to point circuits or application specific layer 2 multipoint broadcast domains Interoperable architectures & control planes needed Integration challenges (control, data, management planes) Multi-layer adaptations “horizontal” for multi-domain Multi-layer adaptations “vertically” for traffic grooming Key control plane functions: routing, signaling, path computation Scheduling and AAA functions also needed Integration of (G)MPLS and Web Services

R&E “Hybrid” Networks l One “infrastructure” which provides basic IP routed service as well deterministic services at lower layer l l l Services could be point to point circuits or application specific layer 2 multipoint broadcast domains Multi-Service, Multi-Layer, Multi-Domain Emerging Hybrid Network environment is driving a new service model: l l l Dedicated end-to-end services will be available at the wide area edge Challenge for Giga. Po. Ps, Regional Optical Networks (RONs), and campuses is how to extend these services from the wide area edge across the regional networks, campus infrastructure, and to the user location. Techniques will depend on the details of the service offerings from the wide area R&E networks, the particular needs of the local user community, and the nature of the available regional infrastructures.

“Hybrid” Network Service Provisioning l Multiple technology options: l MPLS, Ethernet, SONET, WDM, Fiber l l Service Interface (user connection) likely to be: l l l Ethernet Port (possibly with specific VLANs) SONET/SDH port (more often for network to network) Multiple provisioning options l l Many solutions will use combinations of the above (i. e. , multilayer) Manual, Management Plane, Control Plane Many issues including AAA, Scheduling, Service Level Agreements, Common Service Agreements, user requirements

What About Web Services? l l There is value to capturing some of these control plane functions in the form of Web Services For DRAGON, that would mean putting a Web Service interface into our GMPLS control plane l l Automatically processing of routing protocols The most basic web service needed is (abstracted) topology representation l l Network Description Language (NDL) seems like a good method for topology (network graph) representations Community needs to agree on a schema

GMPLS and WS Control Plane Overlap l l Idea – All participating control planes must have a common set of topology discovery, routing, path computation and signaling functionality. Methodology – Translate the “key” GMPLS-CP functions into WS-CP counterparts in web services notations WS-CP GMPLS Signaling Protocols WS Provisioning and Scheduling Services Multi-Layer Inter-Network Path Computation GMPLS Path Computation Algorithms & Protocols WS Path Computation Services Topology Description Advertisement & Routing GMPLS Routing Protocols WS Routing Services Inter-Network Signaling Common Internetworking Infrastructure Services Registration and Discovery Secure Messaging Context Management Mutual Trust Policy Exchange

WS-CP Structure Web Service Wrappers

Conclusions l l Any control plane will have to address routing, path computation, and signaling GMPLS represents the most advanced set of thinking, concepts, and capabilities in this area l l Need to track and leverage these concepts, standards activities, and vendor implementations to the maximum extent possible There is value in capturing some of these functions via web services l l Particularly topology descriptions Need to agree on a schema (i. e. , NDL)

Conclusions l Expect a future environment where some peering networks will use GMPLS and some use Web Services l l l Should be able to accomplish multi-domain provisioning in this environment This will allow interoperation between GMPLS and non-GMPLS networks (or Web Service and non-Web Service networks depending on your viewpoint) Most participants in this community have a per domain controller/manager l We should strive to define the Inter. Domain communications required for both: l l l GMPLS style control plane Web Service style control plane Future will likely be mixture of both

Control Plane Standards Activities

GMPLS Interdomain Routing and Signaling Solution DRAGON comparison to OIF l Similar in overall concept in terms of l l Many differences in the details Domain/Routing Controllers l l l OIF OSPF daemons are called Routing Controllers (RC); RC ID = Router ID l One or more RC in each routing domain as routing speakers for the domain DRAGON has the Network Area resource Broker (NARB) as RC, which has no corresponding router and operates a dedicated instance of OSPF in a separate address space Both have adjacency via IP tunnels and control communications via separate tunnel addresses OIF introduces Local/Remote Node ID sub-TLV for separation of data plane from control pane (each RC can correspond to multiple routers (nodes)) and Hierarchy List sub-TLV to add vertical hierarchies to TE topology. Connection End Points l l l use of hierarchical link state (OSPF derived) for routing RSVP for signaling OIF UNI uses TNA w/ Node ID addresses, which introduces Reachable TNA Opaque LSA and Node ID sub-TLV into OSPF-TE advertisement DRAGON uses edge router loopback IP with Local-ID, which introduces Local-ID to end users but does not add anything into the OSPF-TE The plan is for DRAGON be become standards compliant as they mature (with hopefully interoperation with other domains providing specific requirements)

Multi-Layer Infrastructures Application Layers Multi-media (Vo. IP, HDTV) E-science, grid, virtualization Storage, data archive, mirroring, peer-peer Virtual reality, data fusion / visualization Diversified “Cyber-Infrastructures” Layer 3 IPv 4, IPv 6, MPLS ESNet + OSCARS Abilene + BRUW DRAGON Layer 2 Ethernet, ATM Layer 1. 5 SONET, GFP, VCAT, LCAS Layer 1 DWDM Ultra Science Net New. Net CHEETAH DRAGON

Multi-Layer / Multi-Domain Focus Scale Services Across Layers Unified Inter-Layer Architecture Resource Discovery • Hierarchical routing • Multi-layer database • Legacy domain (proxy) • Temporal state Path Comp, Scheduling • Distd / centralized • Domain controllers • Path composition • Adv. scheduling Signaling & Recovery Security, AAA • Multi-layer LSP: • Encryption Stitching, merging • Integrity • Multi-layer recovery • Client validation • Signaling extensions Need R&D, new standards, vendor support

Standards Tracking Multi-Layer / Multi-Domain Activities IETF WG’s Architectures, protocols, L 1 VPN Liaison Activities OIF Networking WG’s UNI, NNI specifications ITU-T SG-15, SG-13 WG Architectures, L 1 VPN

Optical Internetworking Forum User Network Interface (UNI) 2. 0 • Multi-vendor interoperable client provisioning Automated end-pt & service discovery, signaling (parameters) • Improved resiliency, control security, Eth support (IETF, ITU-T inputs) • UNI-N side supports multi-layer call/connections (VCAT) Network to Node Interface (Internal – NNI, External - NNI) • Decouple intra & inter-domain mechanisms (protocols, algorithms) • Signaling protocol: parameter negotiation, protection/diversity • Hierarchical routing: topology / resource discovery • Generally lacks provisions for advance scheduling IEC Supercomm interoperability trials • Interim UNI 1. 0 (2001): End-pt discovery, setup/teardown, full λrates • UNI 2. 0, E-NNI 1. 0 (2005): 13 vendors, 7 service providers (focus on Eo. S services)

International Telecom Union (ITU -T) Automatically-Switched Optical Network (SG - 15, G. 8080) • Multi-level hierarchical link-state routing (G. 7715. x): Horizontal (areas), vertical (leaders), inter-level state exchange • Distd call / connection management (G. 7713. x, SN controllers): Recently addressing protection/restoration, no crankback yet Layer 1 VPN (SG - 13) • Req & architecture documents (Y. 1312 / 2003, Y. 1313 / 2004) • Close liason w. IETF (routing area) on suitability of IETF protocols Other liason activities to evolve “ASON compliant” protocols • Signaling: IETF RSVP-TE drafts for ASON, OIF UNI 2. 0 & NNI 1. 0 alignment • Link-state routing: - Reqs RFC 4258, OSPF-TE and IS-IS drafts for ASON (G. 7715. 1) - OIF NNI 1. 0 routing

Internet Engineering Taskforce CCAMP working group (GMPLS) • GMPLS control for SONET/SDH (RFC 4257) • GFP/LCAS interface discovery (OSPF-TE, RSVP-TE implications) • Multi-layer/multi-region (MRN) networks drafts: Interface switching capability (ISC), unified TE database • Drafts on multi-domain routing (OSPF-TE, O-BGP), no temporal state • Other drafts on multi-domain/AS signaling & recovery: Crankback, inter-AS exclude routes, etc Path computation element (PCE) working group (TE) • Path composition for TE-LSP paths: Centralized / distributed, loose-domain / hop-by-hop • Inter-area / AS / layer considerations (virtual topology management) • New PCEP signaling protocol, possibly one for PCE discovery • No PCE considerations for advance scheduling • Various requirements drafts (2004 -5), no RFC yet

IETF Multi-Layer Network Overview • Networks w. multiple domains, , nodes w. multiple layers • Run single GMPLS instance (routing, signaling): - Multiple links in TE database (TED) w. FA-LSP, ISC - Node-internal links for multi-layer nodes • Path-computation can use ISC to qualify links • Virtual network topology (VNT) via TE links @ lower layers • Inter-domain aspects not addressed in drafts IP/MPLS Horizontal link Vertical link DWDM, TDM Mixed IP, MSPP

IETF L 1 VPN Framework Layer 1 VPN working group • “Infrastructure virtualization”: DWDM lighpath, SONET circuit • Basic and enhanced modes: signaling only vs. distd signaling & routing • Drafts on BGP & OSPF PE discovery (opaque LSA), single AS focus for now • Proposal to extend RSVP-TE signaling (per VPN instances) • Framework draft (near last call), no RFC yet

IETF L 1 VPN Service Models Differing Levels of CE-PE Functionality / Exchange

Questions? network@internet 2. edu