JSRs: Java Specification Requests
JSR 25: JAINTM Connectivity Management Specification
Reason: Withdrawn at the request of the submitter.
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0
The JSR is to define the Java APIs for a Connectivity Management API specification.
Please direct comments on this JSR to the Spec Lead(s)
Section 1. Identification
Pramila Mullan, AT&T
James Scriba, AT&T
The JSR is being submitted and endorsed by the following Java Community Process Participants:
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:
2.1 What is Connectivity Management?
Connectivity Management is:
Connectivity Manager enables users to control the following characteristics of a network via the following Connectivity attributes:
Connectivity Management is NOT:
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
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
2.12 Existing specifications needing revisions
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":
"Policy Framework Core Information Model":
"Directory Enabled Networks":
"Security Policy System":
Heinanen, J. et al., "Assured Forwarding PHB Group" February, 1999;
Bernet et al., "A Framework for Differentiated Services," February, 1999; http://search.ietf.org/internet-drafts/draft-bernet-dclass-00.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;
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";
E. Rosen, et al., "BGP/MPLS VPNs";
D. Jamieson, et al., "MPLS VPN Architecture," August 1998;
Heinanen, J. et al., "Assured Forwarding PHB Group;" February, 1999;