Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 25: JAINTM Connectivity Management Specification

This JSR has been Withdrawn
Reason: Withdrawn at the request of the submitter.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Contact Information:

Pramila Mullan, AT&T
Phone: +1 732 420 3698
Email: pmullan@ems.att.com

James Scriba, AT&T
Phone: +1 408 576 1419
Email: jscriba@ipo.att.com

The JSR is being submitted and endorsed by the following Java Community Process Participants:

  • AT&T
  • BT
  • Sun Microsystems
  • Telecordia

Section 2: Request

The JSR is to define the Java APIs for a Connectivity Management API specification. It will describe a Java environment derived from specifications that encompass varying layers of interfaces for controlling connectivity in intelligent IP networks. Connectivity Management is a collection of services for dynamically providing connectivity with specified QoS, security, and routing attributes in IP networks. It provides interfaces that enable entities utilising the APIs to request services, and it enforces defined policies in providing these services to entities that are presented via Application Program Interfaces (APIs).

Such services should include:

  • signaled and provisioned QoS in IP networks
  • secure IP transport (using IPSec)
  • IP routing , including VPN-aware routing
  • user access control (for example, dial-in user)
  • IP packet filtering
  • IP address translation

2.1 What is Connectivity Management?

Connectivity Management is:

  • A set of functions that provide configuration and control of both the attributes of IP connectivity and policies governing IP connectivity, within and between IP domains. Such attributes include QoS, security, and routing policy.
  • The interfaces made available to users of an IP platform to invoke and control these attributes.
  • The interfaces made available to management applications used to configure, monitor, and control the network.
  • The interfaces used to enable cross-domain services. These functions can be invoked through a number of open interfaces, including APIs used by management applications, control protocol interfaces to the IP network, and control interfaces to peer functions in other domains.
  • The mechanisms and interfaces needed to provide interoperability and to control equipment from multiple vendors.

Connectivity Manager enables users to control the following characteristics of a network via the following Connectivity attributes:

  • Quality of Service specifying packet loss, delay, rate control, and throughput.
  • Security policy whether packets should be encrypted and /or authenticated using IPSec.
  • Tunneling and encapsulation (for example, L2TP).
  • Traffic Engineering: routing traffic trunks in order to meet requirements of resilience, priority, preemption, bandwidth optimization, load balancing, etc.
  • Access control (packet filtering, etc.).
  • NAT Policy.
  • Multicast.
  • Service Level Agreements (SLAs): SLAs may be specified for an individual pipe or hose within the Virtual Private Network (VPN). The SLA will determine how to monitor the pipe or hose and how to report exceptions.

Connectivity Management is NOT:

  • Replacement or bypass of control protocols within the IP network, such as routing, signaling and peer-to-peer key exchange. Rather, it operates in conjunction with these functions, to configure, apply policies, and obtain feedback from these protocols.
  • Prescription for a single mechanism for the establishment of enhanced IP connectivity. Instead, it provides a framework for establishing an enhanced IP connectivity in a number of ways with the necessary controls applied. In many cases, the manner of establishing connectivity, or the adjustment of connectivity attributes, will depend on the required time scale. The framework will accommodate signaled "dynamic" establishment of connectivity, as well as long-term provisioned "static" establishment.
  • A manager of all necessary management functions related to these attributes, including fault handling, accounting, performance monitoring, and others. Instead, it enables configuration and control of IP connectivity attributes. However, to enable the effective operation of these functions, Connectivity Management does interact with the network management functions, as a minimum by making the necessary configuration and control information available.

2.2 Target Java Platform

The JAIN Connectivity Management APIs are targeted towards control and management of Central Office switching and routing environments, or network elements. As such policy servers, databases, proxies, configuration servers, and policy decision/ servers will be used to implement the Connectivity Management architecture.

2.3 The Needs of the Java Community this Specification Addresses.

Today, network services are built using proprietary interfaces. These interfaces are often specific to the hardware and software of that network. This result in single supplier based vertically integrated solutions with high costs to develop and maintain services. JAIN CM aims to provide vendor independent APIs in order to control CM within IP networks. Connectivity Management should provide configuration of network services in a way, which enables connectivity to be configured on network devices from multiple vendors.

The JAIN Connectivity Management APIs define a Java version of the CM APIs which enable entities to rapidly build and deploy applications that exploit the CM capabilities as described above of the underlying IP network. With Connectivity Management, the Java community can add greater functionality to existing signalling APIs that already exist in the Java community (e.g. Java RSVP API).

Section 2.4 The API being Defined

The API specified by the Connectivity Management group in JAIN is based on work done by AT&T and BT. The activity will translate existing specifications and UML into a set of Java interface packages.

Section 2.5 Underlying technologies

The JAIN Connectivity Management APIs abstract underlying network capabilities such as routing management and control, policy management, security management, and QoS control. These APIs are independent of existing routing, policy and signalling protocols and specifications standardised for and implemented in IP networks.

The APIs operate on secure servers and may be offered to internal and external applications.

In the case of policy, many IETF specifications cover policy schema, architecture, security, framework, and the terms that define policy. The need to link policy as defined by these specifications for control of QoS, routing, and security to other specific functions and devices in a service domain requires implementation of a management framework. This management framework interacts with these functions and devices via a set of APIs.

Other underlying technologies include routing protocols, QoS architectures and protocols, and security frameworks and protocols. A list of many of the documents defining these technologies can be found in the appendix.

Section 2.6 Proposed Package Names

jain.cm

This package contains the main interfaces, classes and exceptions required supporting connectivity management.

2.7 Security implications

JAIN Connectivity Management API will make it possible to build generic software environment using JAVA and associated technologies. Risks include failure of the Java platform due to poor performance or the inability to failover or recover.

Implementation of the interfaces in a secure environment is important especially at user and application level for control of network resources.

2.8 Possible platform dependencies

In deployment, the API can use a variety of distribution mechanisms such as RMI or CORBA.

The decision of who builds the Reference Implementation and what it distribution technology it implies is as yet undecided.

2.9 Internationalisation implications

None, the Connectivity Management specification is based on international standards and will permit the use of the globally. Connectivity management is being added to Parlay Phase 2 and being considered for other standardisation initiatives.

2.10 Risk assessment

JAIN CM moves Java into the IP middleware domain. This activity solely defines the APIs and cannot stipulate the internal implementation of a specific vendor's products.

However to accompany any future product description that acknowledges adherence to the JAIN CM API there must be evidence to demonstrate reliability, scalability, and availability necessary for multimedia communication networks. Performance evaluation and tests based on API architecture may be published with each release of a vendor product or operator service.

2.11 Existing specifications rendered obsolete or deprecated

Not applicable.

2.12 Existing specifications needing revisions

Not applicable.


Section 3: Contributions

Documents describing JAIN can be found at http://java.sun.com/products/jain/index.html


Section 4: Additional Information

Documents describing Protocols and policy mechanisms involved in CM can be found in the following documents:

"Terminology for describing network policy and services":

http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt

"Policy Framework Core Information Model":

http://www.ietf.org/internet-drafts/draft-ietf-policy-core-schema-01.txt

"Directory Enabled Networks":

http://www.murchiso.com/

"Security Policy System":

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sps-00.txt

Heinanen, J. et al., "Assured Forwarding PHB Group" February, 1999;

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-af-06.txt

Bernet et al., "A Framework for Differentiated Services," February, 1999; http://search.ietf.org/internet-drafts/draft-bernet-dclass-00.txt.

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-framework-02.txt.

Bernet, "Usage and Format of the DCLASS Object With RSVP Signaling," February, 1999; http://search.ietf.org/internet-drafts/draft-bernet-dclass-00.txt.

Mehra, A. and Verma, D., "Architectural Considerations for DiffServ Servers," February, 1999; http://search.ietf.org/internet-drafts/draft-mehra-diffserv-servers-00.txt.

Rajan, R., "Schema for Differentiated Services and Integrated Services in Networks," October, 1998; http://www.ietf.org/internet-drafts/draft-rajan-policy-qosschema-00.txt.

Berger et al., "Extensions to RSVP for LSP Tunnels," February, 1999;

http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-01.txt.

Braden, R. and Hoffman, D., "RAPI -- An RSVP Application Programming Interface," Internet Draft, August 1998; http://www.isi.edu/rsvp/DOCUMENTS/rsvpapi.txt

Berger, L., O'Malley, T., "RSVP Extensions for IPSEC Data Flows," RFC 2207, September 1997, Proposed Standard; ftp://ftp.isi.edu/in-notes/rfc2207.txt.

Lindell, B., "SCRAPI - A Simple "Bare Bones" API for RSVP," Internet Draft, February 1999; http://www.isi.edu/rsvp/DOCUMENTS/draft-lindell-rsvp-scrapi-02.txt.

Shenker, S. and Wroclawski, J. "General Characterization Parameters for Integrated Service Network Elements;" September 1997; RFC 2217; http://www.ietf.org/html.charters/intserv-charter.html

J. Heinanen, et al., "VPN support with MPLS";

http://search.ietf.org/internet-drafts/draft-heinanen-mpls-vpn-01.txt

E. Rosen, et al., "BGP/MPLS VPNs";

http://search.ietf.org/internet-drafts/draft-rosen-vpn-mpls-01.txt

D. Jamieson, et al., "MPLS VPN Architecture," August 1998;

http://search.ietf.org/internetdrafts/draft-jamieson-mpls-vpn-00.txt

Heinanen, J. et al., "Assured Forwarding PHB Group;" February, 1999;

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-af-06.txt

http://www.ietf.org/internet-drafts/draft-rajan-policy-qosschema-00.txt