Transcript The HOPI Testbed and the new Internet2 Network

Internet2 Network Tutorial:
Control Plane and Dynamic Services
Rick Summerhill, Matt Zekauskas, Russ Hobby
Internet2
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 Internet2 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
Internet2 (HOPI) taking an Ethernet VLAN approach
Internet2 (Ciena) taking a SONET approach
GEANT is taking a SONET approach
HOPI Testbed Overview
• Nodes located in 5 major cities on the Internet2
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 Internet2 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
Internet2 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
CSA
2
CSA
Client A
a
Ethernet Mapped SONET
or
SONET Circuits
Internet2 DCS
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
Internet2 DCS
Ethernet Mapped SONET or SONET Circuits
Inter-Domain
Domain
Controller
Domain
Controller
Domain
Controller
CSA
CSA
RON Dynamic Infrastructure
Ethernet VLAN
RON Dynamic Infrastructure
Ethernet VLAN
Internet2 DCS
Ethernet Mapped SONET
DRAGON Control Plane
Status and Adaptation to Internet2
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
 Thoughts/Considerations regarding
Evolution to Internet2 Control Plane
 Advanced Topics: Web Services,
AAA, Scheduling
 Next Steps and Timelines

DRAGON Control Plane
Key Components

Network Aware Resource Broker – NARB


Virtual Label Swapping Router – VLSR



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


Intradomain listener, Path Computation, Interdomain Routing
End system or client software for signaling into network (UNI or
peer mode)
Application Specific Topology Builder – ASTB


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





Multi-Domain Provisioning
Interdomain ENNI (Web Service and OIF/GMPLS)
Multi-domain, multi-stage path computation process
AAA
Scheduling
Internet2
Network
RON
RON
Dynamic Ethernet
Domain Controller
Ctrl Element
Ethernet
SONET Switch
Router
GEANT
Dynamic Ethernet
TDM
ESNet
Data Plane
Control Plane Adjacency
LSP
IP Network (MPLS, L2VPN)
DRAGON/HOPI Control Plane
Provisioning Environment
GMPLS Multi-layer, Multi-Domain
Ethernet Service Provisioning
Dynamic dedicated VLAN based
connections



IGP-TE
IGP-TE
GMPLS Provisioned LSP
Dedicated Ethernet VLAN “Circuit”
UNI
SEA
LA
CHI
Ethernet Layer
NY
GWU
DC
MCLN
HOU
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
IP Control Plane
AS 3
IP Control Plane
VLSR
VLSR
Ethernet over
WDM
End
System
Ethernet Segment
VLSR Established VLAN
Ethernet over
SONET
Router MPLS LSP
End
System
Ethernet
Lambda Switch
SONET Switch
Router
Ethernet Segment
VLSR Established VLAN
DRAGON Control Plane
Interoperation with Ciena Domain

Three Options


GMPLS



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




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)

Same as above but use a “management style” system which talks to
Ciena Domain via UNI or ENNI
Ongoing Ciena Testing





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 UNI2.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)




GMPLS Proxy
 (OSPF-TE, RSVP-TE)
Local control channel
 CLI,TL1, 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)

RSVP Signaling module







OSPF Routing module




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

Dell PowerConnect, Extreme, Intel, Raptor, Force10
NARB
Network Aware Resource Broker

Interdomain Routing


Carries a modified TEDB that can support



hierarchical link state
AAA
Scheduling
Path Computation Element and ERO (loose and strict) generation
InterDomain Exchange
NARB
NARB
NARB
End
System
End
System
AS 1
AS 2
AS 3
NARB
(Network Aware Resource Broker)


NARB is an agent that represents a domain
Intra-domain Listener



Inter-domain routing




Peers with NARBs in adjacent domains
Exchanges (abstracted) topology information
Maintains an inter-domain link state database
Path Computation




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 (3D RCE)”



The Traffic Engineering DataBase (TEDB) and Constrained Shortest Path
Computation (CSPF) are extended to include dimensions of GMPLS TE
parameters, AAA constraints, and Scheduling constraints.
3D RCE is the combination of 3D TEDB and 3D CSPF
http://dragon.east.isi.edu/data/dragon/documents/dragon-infocom-APBMworkshop-apr282006.pdf
What is the HOPI Service?

Physical Connection:


Circuit Service:




Point to Point Ethernet VLAN Circuit
Tagged or Untagged VLANs available
Bandwidth provisioning available in 100 Mbps increments
How do Clients Request?




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?

Anyone who connects to an ethernet port on an HOPI Force 10 Switch;
could be RONS, GIgaPops, other wide area networks, end systems
GMPLS Provisioned
Ethernet Services
“Local ID” for
Egress Control
User Requests:
VLSR PC
Ethernet
switch
VLSR PC
Ethernet
switch







•Peer to Peer
•UNI
•XML API
VLSR PC
VLAN XX LSP
Ethernet
switch
VLSR PC
Ethernet
switch
VLAN YY LSP
VLSR PC
Ethernet
switch
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

Local ID defines the VLAN tag/edge port mapping



OSPF






proprietary Unnumbered Interface ID Subobjects (UnNumIfID) used to encode
VLAN information in ERO
32-bit UnNumbered Interface ID: type(1byte):value(24bits, vlan tag info)
NARB/RCE




configure vlans on each interface
advertise out in IfSwCap 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


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 UnNumIFID objects
Driven by need to provision across HOPI (10 gigabit interfaces)
DRAGON
Provisioning Web Page
Web Page Interface
Application Specific Topologies
using XML
C
<topology>
A
<resource>
<resource_type> eVLBI.Mark5a
<name>
Haystack.muk1
<ip_addr> muk1.haystack.mit.edu
<te_addr> muk1-ge0.haystack.mit.edu
<appl>
/usr/local/evlbi_script
</resource>
<resource>
<resource_type> eVLBI.Mark5a
<name>
Westford1
<ip_addr> wstf.haystack.mit.edu
<te_addr> wstf-ge0.haystack.mit.edu
<appl>
/usr/local/evlbi_script
</resource>
<resource>
<resource_type> EtherPipeBasic
<src>
Haystack.muk1
<dest>
Westford.muk1
<datarate>
1 Gbs
</resource>
</topology>
B
</resource_type>
</name>
</ip_addr>
</te_addr>
</appl>
</resource_type>
</name>
</ip_addr>
</te_addr>
</appl>
</resource_type>
</src>
</dest>
</datarate>
A
B
C
Application Specific Topologies


Live demonstration at Internet2 Spring Member Meeting (April 2006,
Washington DC)
 See www.internet2.edu for webcast of “HOPI update” presentation.
Set up global multi-link topologies
 ~30 seconds
Internet2 Network: Infrastructure with
Multiple Services
“ Routed IP
Network”
Router Layer
Ethernet Layer
Switched SONET
Layer (vcat, lcas)
Provisioned
Topologies
“SONET
Switched
Network”
Switched WDM
Optical Layer
Ethernet
Layer
Switched SONET
Layer (vcat, lcas)
“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

Physical Connection:



Circuit Service:





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?




1 or 10 Gigabit Ethernet
OC-3, OC-12, OC-48, OC192 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?

A Device on the network requesting a circuit connection
Control Plane Objectives

Multi-Service, Multi-Domain, Multi-Layer,
Multi-Vendor Provisioning


Basic capability is the provision of a “circuit” in
above environment
In addition, need control plane features for:



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)

Routing


Path computation


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

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

Domain Summarization




Multi-layer “Techniques”




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, L2SC, 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


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
CoreDirector
CoreDirector
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.
I2 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 Internet2 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 Internet2 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
Summarized/Abstract InterDomain Topoloy (A single link state flooding area)
NARB
w/RCE
NARB
w/RCE
NARB
w/RCE
IntraDomain Topoloy - Area 2
IntraDomain Topoloy - Area 1



IntraDomain Topoloy - Area 3
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.
E2E Multi-Domain Path
Computation Scheme
DRAGON mainly uses Recursive Per-Domain (RPD) interdomain path
computation
Strict Hops
Loose Hops
2
request
1
request
6
full path
Strict Hops
NARB
w/RCE
5
expand
Loose Hops
3
4
request
expand
Strict Hops
NARB
w/RCE
NARB
w/RCE
Domain 2
Destination
Source
Domain 1


Domain 3
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

A breadth first search based CSPF heuristic in
deployment




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
(~30ms 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

AAA Rules
Resource dimension

Feasible Solution (LSP)




Solution Space
Resources


AAA policy dimension

Time
Schedule

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 (3D)
Resource Computation Model
AAA Rules
Resource states, time schedule and AAA policies
are exchanged among control-plane entities
in both intradomain and interdomain scopes.
Feasible Solution (LSP)
Time
Schedule
Solution Space
Resources
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)
API Interface
RCE
Protocol
LSP Schedule
Table
AAA Rules
Table
3D CSPF PCEn


Interfaces
OSPF API
RCE Server
API
Interdomain E2E
path computation
Other
API's
3D TEDB
Support
Advance scheduled
service provisioning
AAA based provisioning
and admission control
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.
3D Constraint Based Path
Computation
Network and Domain
Policies
LSP Request
Check Out
Affecting
Rules
AAA Rules
Table
User Specified
Rules
LSP
Schedule
TEDB
Rule Parser
Rule Parser
Data source (raw link
states from intra- and
inter-domain flooding)
and 3D constraints
AAA
Rule
Filter
Snapshot of
topology reduced
by policy filters
Existing
Resource
Reservations
Time
Window
Filter
Constraint based
path computation
algorithm - CSPF
heuristics
User Schedule Constraints
CSPF Routing
Algorithm
LSP Path
Reduced Topology
AAA Based Provisioning
Type = 1
0
8
Type = TBD
16
24
31
Length = Variable
Length = 12
User ID
Rule (Action/Restriction)
AAA policy rule sub-TLV(s)
Local Resource ID
AAA policy refence ID sub-TLV(s)
Type = 2
Length = 4
Policy Reference ID




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
0
8
16
24
31
Type = TBD
Length = N*5
Resv 1 – Start time
Resv 1 Duration
Resv 2 – Start time
Resv 2 - Duration
Resv 3 ...
Repeated N times (N ≤ 40)
Schedule TE Link TLV
 Allows a time constraint to be included
as part of path computation

Continuing Work
Key Focus Areas

GMPLS Control Plane

Inter-domain routing and signaling agreements







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


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)
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
IP Control Plane
AS 3
IP Control Plane
VLSR
VLSR
Ethernet over
WDM
End
System
Ethernet Segment
VLSR Established VLAN
Ethernet over
SONET
Router MPLS LSP
End
System
Ethernet
Lambda Switch
SONET Switch
Router
Ethernet Segment
VLSR Established VLAN
InterDomain
(G)MPLS and Web Services

Currently working on interdomain virtual circuit
provisioning between:





ESnet
Abilene
HOPI
UltraScience 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










Multi-Service, Multi-Level, Multi-Domain
One “infrastructure” which provides basic IP routed
service as well services at lower layer
 i.e., connectionless and connection oriented services
Services could be point to point circuits or application
specific layer2 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

One “infrastructure” which provides basic IP routed
service as well deterministic services at lower layer



Services could be point to point circuits or application specific
layer2 multipoint broadcast domains
Multi-Service, Multi-Layer, Multi-Domain
Emerging Hybrid Network environment is driving a new
service model:



Dedicated end-to-end services will be available at the wide area
edge
Challenge for GigaPoPs, 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

Multiple technology options:

MPLS, Ethernet, SONET, WDM, Fiber


Service Interface (user connection) likely to be:



Ethernet Port (possibly with specific VLANs)
SONET/SDH port (more often for network to network)
Multiple provisioning options


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?


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


Automatically processing of routing protocols
The most basic web service needed is
(abstracted) topology representation


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


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-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
Registration and Discovery
Common Internetworking
Infrastructure Services
Secure Messaging
Context Management
Mutual Trust
Policy Exchange
WS-CP Structure
Web Service Wrappers
<wsdl:operation name="getNetworkTopology">
<wsdl:operation name="getAdjacentNetworkList">
<wsdl:operation name="getPathComputationResult">
Intra-Network Path
Computation
Service
Inter-Network Path
Computation
Collaboration Service
Topology
Description &
Discovery Service
Multi-Layer PCE
Inter-Network Path
Computation Logic
TEDB
Signaling &
Management
Topology
Summrization
Scheduling
Network
Description
Language
Network Controller
Core Functions
UDDI
Inter-Network
Signaling
Service
Inter-Network
Scheduling
Service
CIIS
Services
Web Services Wrappers
<wsdl:operation name="createInternetworkPathComputationSession">
<wsdl:operation name="getRecursivePathComputationResult">
<wsdl:operation name="createPathReservation">
<wsdl:operation name="createAdaptationCrossConnect">
Conclusions


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


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


Particularly topology descriptions
Need to agree on a schema (i.e., NDL)
Conclusions

Expect a future environment where some peering
networks will use GMPLS and some use Web Services



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

We should strive to define the InterDomain communications
required for both:



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

Similar in overall concept in terms of




Many differences in the details
Domain/Routing Controllers





OIF OSPF daemons are called Routing Controllers (RC); RC ID = Router ID
 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



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
(VoIP, HDTV)
E-science, grid,
virtualization
Storage, data archive,
mirroring, peer-peer
Virtual reality, data
fusion / visualization
Diversified “Cyber-Infrastructures”
Layer 3
IPv4, IPv6,
MPLS
ESNet
+ OSCARS
Abilene
+ BRUW
DRAGON
Layer 2
Ethernet, ATM
Layer 1.5
SONET, GFP,
VCAT, LCAS
Layer 1
DWDM
Ultra
Science
Net
NewNet
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,
L1 VPN
Liaison Activities
OIF Networking WG’s
UNI, NNI specifications
ITU-T SG-15, SG-13 WG
Architectures, L1 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 EoS 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 L1 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
Centralized Management Control
Customer
OSS
Carrier
OSS
CMN interface
Customer
OSS
CMN interface
Provider network
PE node
P node
CE node
Customer networks
Customer networks
Distributed GMPLS Control
Customer networks
Customer networks
Provider network
PE node
CE node
P node
L1 VPN service
interfaces
IETF L1 VPN Service
Models
Differing Levels of CE-PE Functionality / Exchange
Questions?
[email protected]