Multi-Layer Hybrid Network Control Plane

The objective of the multi-layer hybrid network control plane development activities are as follows:

• Develop a control plane architecture that enables multi-domain, multi-layer, multi-service provisioning which includes features for authentication, authorization, and accounting (AAA) and scheduling.
• Develop a roadmap for each of the existing network control planes to incorporate the features required to realize the above feature set.
• Develop a set of inter-domain protocol agreements such that the individual networks have a common set of messages to exchange to enable these capabilities.
• Develop a comprehensive security architecture and a best practices guide for hybrid network control planes.
• Develop and release open source control plane software for use on these and other hybrid networks.
• Develop both a GMPLS control plane (GMPLS-CP) and a Web service control plane (WS-CP) as described below.
• Utilize these control planes to realize hybrid network services across ESNet, USN, HOPI, Abilene, and DRAGON infrastructures.

This tasks focus is on the design and performance evaluation of scalable control plane/provisioning architectures for hybrid multi-layer networks. In particular, the key efforts will focus on the following architectural areas: 1) inter-layer routing, 2) inter-layer path computation and scheduling, 3) inter-layer signaling, and 4) inter-layer survivability. An overriding requirement here will be to ensure that the proposed solutions, possibly generic in nature, can be directly tailored to the specific R&E networks involved in this project. The key features of any control plane are:

• Routing - distribution of "data" between network areas or domains. The data that needs to be distributed includes reachability information, resource usages, etc
• Path computation - 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 service 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 service based exchanges might employ a modified version of this technique or something entirely different.

These functions then get applied to various tasks like circuit provisioning, protection, restoration, and traffic engineering. Accomplishing these tasks in a multi-domain, multi-layer, multi-service hybrid network environment is considerably more difficult than the efforts to date which have focused primarily on single domains/technology layers. Additional functions like AAA, scheduling, and security then need to be integrated with these other control planes functions. This is the primary challenge of the control plane development activities. Whether these capabilities are then expressed via a native GMPLS set of protocols (OSPF-TE, RSVP-TE) or abstracted out via a web service construct does not change the requirement to solve the associated technical issues. The likely answer is expected to be a combination of GMPLS exchanges along with higher level web service functions.

These control plane development activities will start with the existing control planes in place on the referenced networks. This is inline with the basic realization that as hybrid networks are deployed, most infrastructures will employ a control plane unique to their organization. However, in order to facilitate interoperation, two key architecture notions will be pursued: i) a GMPLS control plane (GMPLS-CP), ii) a Web service control plane (WS-CP). A brief summary of the WS-CP concept is provided below.

Web Service Based Control(Service) Planes

The key control plane architectural components in our solution approach are the Web Service User to Network Interface (WS UNI), External-Network Network Interface (WS E-NNI), and Internal-Network Network Interface (WS I-NNI IF). The WS-UNI defines client service request structures. The WS E-NNI defines web service functions for inter-network routing/topology exchange, path computation/scheduling, and signaling/path setup. While these capabilities are inspired by the standards on control plane protocols, they do more than simply recreating that work at the web service level. One of the benefits, and driving motivations, to follow a Web Service framework is the built in security mechanisms available. A robust and flexible set of capabilities to incorporate encryption, message integrity, authentication, and authorization is essential to hope for any degree of multi-domain adoption. This includes an ability for a client to authenticate a server (i.e. Domain Controller), as well as for the Domain Controller to be able to authenticate AND apply policy based processing to user requests. Basic SSL over HTTP will be utilized for the former. However, the latter is a complex space and the Web Service Security (WSS) specification by OASIS is being utilized as the basis to solve these issues. The WSS framework provides a method to include message signatures, authentication tokens, and authorization credentials in the header of a SOAP message. This includes the use of X.509 certificates and Security Assertion Markup Language (SAML) assertions as tokens in the SOAP header to provide the required mechanisms to allow policy based user request processing and provisioning. SAML assertions contain information that can be used to make user access and provisioning decisions. Due to space limitations, the details of the certificate formats, user attribute definitions, and associated SAML assertions are not reviewed here. In summary, the benefits offered by Web Services include:

• standardized mechanisms for user authentication and policy management

• flexible features for interfacing with a diverse set of I-NNI mechanisms

• allowing focus on several issues that current control plane work has not addressed in a robust manner: scalability, stability, security, flexible application of policy, AAA, and scheduling

While there is some overlap and parallels with the ASON,OIF,IETF-CCAMP UNI/I-NNI/E-NNI work there are also some key distinctions. The standards bodies:

• have not converged on Inter-AS interdomain E-NNI routing or signaling protocols

• completed very little work on application of an Authentication, Authorization, Accounting (AAA) model for the control plane

• completed very little work on scheduling of provisioned services

• are not addressing scalability and security to the degree required for the R&E community

In addition, use of a Web Service technique between some domains will still allow for other peering domains to utilize non web service E-NNI (i.e. GMPLS based) as desired. This heterogeneous style control plane interconnect is anticipated to be the result of regional networks preferring to use a GMPLS based E-NNI when connecting with a trusted wide area network while the interdomain connections between peering international wide area networks is likely to be based on Web Services.

Below are some diagrams of the Web Service Control(Service) Plane architecture.

• WS-CP Architecture:
  

• WS-CP Flow Diagram:
  

-- TomLehman