Question(s):	14/15, 12/15		Meeting, date:	Chicago, February 16 – 20, 2004
Study Group:	15	Working Party:	3
Source:	Q14
Title:	Response to IETF CCAMP WG regarding Comments on G.7713.2
LIAISON STATEMENT
To:	IETF CCAMP chairs - Adrian Farrel, Kireeti Kompella
Cc:	IETF Routing Area Directors – Alex Zinin, B. Fenner
Approval:	ITU-T SG15 Q14/15 Rapporteur Meeting
For:	Action
Deadline:	12 April 2004
Contact:	Hing-Kam Lam Lucent Technologies USA			Tel: +1 732-949-8338 Fax: +1 732-949-1196 Email: hklam@lucent.com

Introduction

Q14/15 acknowledges the liaison received from CCAMP regarding G.7713.2 and thanks CCAMP for the effort and detail of their comments. To progress jointly on the use of GMPLS RSVP-TE for ASON signalling, this liaison provides additional context for ASON signalling that derives from G.8080 architecture and transport business scenarios. It is intended to provide more clarity to requirements that contributed to constructs in G.7713.2.

An examination of the problem statement and principles used in ITU-T and IETF is described with the intention of understanding what may have lead to divergence in solutions. This may assist in the resolution of detailed issues. We invite CCAMP WG to consider the points raised in this liaison to further collaboration on development of ASON signalling solutions.

Problem Statement

Q14/15 participants discussed their understanding of the ASON and GMPLS control plane objectives, which is provided below.

Within the ITU-T, the goal of the ASON work effort has been to support services through the automatic provisioning of end-to-end G.805 transport connections across one or more managerial/administrative domains (e.g., geographic region, G.805 layers, operator/enterprise domains, etc.). This involves both a service and connection perspective:

• The Service (call) perspective is to support the provisioning of end-to-end services while preserving the independent nature of the various businesses involved.
• The Connection perspective is to automatically provision G.805 “path layer” connections (in support of a service) that span one or more managerial/administrative domains.

Within the IETF, the goal of the GMPLS control plane work effort has been to support the automatic provisioning of end-to-end services through implicit/explicit label-switched connections using IP-based control technologies while preserving the independent nature of the various managerial/administrative domains.

The two service goals appear to be very similar, though the degree of independence assumed may not be equivalent, and this had not been evident due to the presence of routers as the sole clients of transport connections in various GMPLS documents. It is now understood by Q14/15 that GMPLS services could be used for non-router clients that do not necessarily even have packet payloads.

Principles used in Architecture, Requirements, and Solutions

During ongoing discussions a fundamental architectural divergence has become apparent, and this may be at the root of many disagreements about the protocol extensions and techniques that are required to meet the functional requirements of ASON. The basis of this divergence can be characterized as a difference of agreement about the "end-to-end" nature of a connection that supports a call. In particular, the use of the Internet “end-to-end” principle in contrast to the use of the call/connection model found in ASON and other connection-oriented services.

Q14/15 understands the Internet end-to-end principle as follows:

• “The end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only at the end points, in such a way that the state can only be destroyed when the end point itself breaks.” (RFC 3439)
• Assignment of functions to the network or the client should depend on the ability of both to handle the function in a meaningful way. This argument was initially used to argue why low-level functions, such as encryption, packet ordering, etc, should be assigned to client systems, not to the network (J. Saltzer)

Q14/15 recognizes that the preferred architectural principle of the IETF is that connections should be end-to-end, and that no service state should be maintained at transit points within the network.

The ASON architecture reflects the policy boundaries that exist in transport networks. These are reflected in reference points between a user and a provider domain (UNI), between domains (E-NNI), and within a domain (I-NNI). The concept of calls and connections is used as the model to realize service across the reference points. Both the UNI and E-NNI are service demarcation points and thus hold call state, which is distinct from connection states throughout the network. Policies are applied at these reference points. Referring to the figure below:

• Calls are end-to-end service associations. Call state is maintained at end points (network access points), and may also be required at key network transit points where it is necessary or desirable to apply policy. In this context, policy may include further path computation, protection management, and restriction of topology visibility, as well as security, authentication and access control.
• When a call spans multiple domains, and hence E-NNIs, it is comprised of call segments. Each call segment runs between a pair of call-state aware points. The concatenation of call segments creates the call.
• Connections are established in support of individual call segments. A single call segment is supported by one or more connections. In general, a single connection does not span multiple call segments (illustrative examples will follow). The collection and concatenation of connections provides end-to-end connectivity.

Example of Call with multiple call and connection segments

Some multi-domain scenarios that require that connection(s) be limited to a single call segment include:

- The service is realized in different ways within each domain (e.g., codecs, technology, QoS).

- Separate address spaces are used within each domain, especially when separately administered.

- There is independence of survivability (protection/restoration) for each domain.

- There is a trust boundary.

- There is lack of knowledge of how the service is realized in another domain (if simultaneous call and connection set-up, or if not possible even when the capability for independent call set-up exists^[1])

- There is an inability to do end-point resolution (if simultaneous call and connection set-up, or if not possible even when the capability for independent call set-up exists¹)

Some multi-domain scenarios that allow for an end-to-end connection across call segments (E-NNIs) are:

- The reason for the domain formation is Billing policy, and/or

- The reason for the domain formation is Call Admission Control/Authentication.

For these latter cases, coordination between call and connection is still necessary to validate that the resources used by the connection are the same as those identified when Call Processing was performed.

It should be noted that the existence of Routing Areas should not be assumed to infer E-NNIs.

Consequence of approach

The key divergence between the two architectures is as follows:

1. In the IETF there is a desire to avoid holding call state at transit nodes, but in ASON this is a fundamental requirement to facilitate service hand-off between domains.
2. In the IETF there is a desire to make the connection end-to-end, where in ASON for most cases it is necessary that the connection be limited to a single call segment.

The application of the end-to-end principle in signalling protocol development in IETF and of the call/connection model in the ITU-T has likely been reflected in:

1. Treating an object as a local or global connection ID.
2. The existence of call identifiers, and associated state, at intermediate points.
3. User resource naming. The ASON service boundary requires the use of network assigned names for user signalling. In the Internet end-to-end model a common global address space between users and networks is used (but consider NAT).

Factors Affecting Q14/15 Signalling Approach

Applying the call/connection model to ASON signalling protocols, and G.7713.2 in particular, has resulted in the following points:

1. G.7713.2 defines call parameters and procedures for the UNI and E-NNI reference points. This enables characteristics of the service to be passed from the user to the network. The network needs to transfer the call parameters to the destination UNI and other intermediate call control points, if present. In G.7713.2 (and other connection oriented protocols), this is done using the connection control protocol and implies the transfer of call parameters over I-NNIs. G.7713.2 does not require storage or interpretation of call information at I-NNIs, only the transferring of this information towards an E-NNI or UNI.

2. It is not apparent from the text in G.7713.2 if call state needs to be stored for the purpose of using the Path message to accomplish refresh over an I-NNI. Thus, we should clarify that call state does not need to be stored at the I-NNI in G.7713.2.

3. It is acceptable that a mapping function exists between reference points such as the UNI and I-NNI even if the protocol base is shared. That the mapping function be trivial is not a requirement from Q14/15.

4. One or more network call controllers (NCCs) participate in a call. This is a consequence of multiple E-NNIs that may be present between two users. At each NCC, call state (parameters) needs to be stored and the NCC-to-NCC relationship is the call segment.

5. Connection segments in the call/connection model are “stitched” together. The terminology used within G.805 is that the end-to-end transport plane connection between users is the “network connection” that consists of both “subnetwork connections” and “link connections” in a single layer network. A “connection segment” as used in ASON terminology represents either a “subnetwork connection” or a “link connection”. Across UNIs and E-NNIs the connection segment is a link connection. Between E-NNIs, the connection segment is either a subnetwork connection or link connection depending on the topology.

In the figure below, distributed control plane entities are illustrated. Between the user and network, there is a UNI reference point. After a call is established to a destination user, a call segment exists between user 1 and the network. It has an associated connection segment that is a link connection. Within domain 1, the NCC at the UNI and the NCC at the E-NNI are involved in the call. This means that there is a call segment between them. If multiple link connections (“hops”) are used then the connection segment is a subnetwork connection. Another way of saying this it that if the connection segment crosses multiple I-NNIs, then it is a subnetwork connection.

I-NNIs are not shown in the figure. If the connection control protocol carries call information, then at the I-NNI, this information is passed along and is not used as part of connection setup at that I-NNI.

Example of Call with multiple call and connection segments

6. As G.7713.2 does not require storage or processing of call information at I-NNIs, it may be possible for G.7713.2 UNIs to be connected over a GMPLS network to other G.7713.2 UNIs assuming that call information can be carried over the GMPLS network.

7. The E-NNI reference point enables restoration of a connection segment within a domain without having to affect connection segments in other domains that are part of the same network connection. This is done by the NCCs that form the corresponding connection segment that is being restored.

8. We understand that there were discussions within CCAMP regarding connection diversity. In the ASON model there is a scenario where a single UNI may need to have call segments to different E-NNIs if there are multiple connections that are associated with the one call but go through different E-NNIs. This is currently an item under study in the G.8080 living list (considered by Q12/15) and G.7713 living list. The intention is to provide multi-homing across UNIs and E-NNIs.

9. Regarding SPCs, the SPC egress label is viewed as a call parameter controlling the remote UNI. This is also found in ATM protocols and reused in G.7713.1. Thus it is passed to the destination NCC.

10. SPCs are used on the edge of an ASON network to connect to clients not having UNI-C control functions. This could be between metro networks or devices that originate/terminate (G.805) connections.

11. One use of UNI Transport Resource addresses at the UNI is for client equipment that does not have bearer or control addresses. The existence of this type of address is found in other connection-oriented services like voice (telephone numbers) and ATM.

Topics where “convergence” can occur

This liaison is not proposing specific solutions for resolving areas of divergence, but provides several observations that may form a basis for a mutually satisfactory resolution.

Within the ASON architecture, a call and a connection can be seen as operating at different scopes. A call is a "service scoped connection" and requires "service scoped connection state" to be maintained at certain intermediate points between source and destination (for example, a connection that is end-to-end within the context of a call segment). It may be possible to map connection segments to tunnels that span subnetworks facilitating an end-to-end connection through those tunnels. It may also be possible to consider connection segments as LSPs that are stitched together.

Independently, a global id for a client connection may be useful for both the GMPLS hierarchy and ASON call/connection model. As discussed earlier, there are some instances where a simple end-to-end connection may be acceptable in the ASON call/model.

We look forward to ongoing collaboration with you in the future.

Hing-Kam Lam,

Rapporteur, ITU-T Q.14/15

______________________________

---

^[1] Note that when call set-up can be performed independent of connection set-up, there is the potential for the call to gather the required knowledge.