CCAMP Working Group L. Ong (Ciena)
Internet Draft J. Sadler (Tellabs)
Category: Informational E. Varma (Lucent)
D. Pendarakis (IBM Research)
S. Shew (Nortel)
Expiration Date: Sept 2004 Feb 2004
Interworking of RFC 3473 and 3474
draft-ong-ccamp-3473-3474-iw-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document defines interworking procedures between [RFC 3473]
(Generalized MPLS (GMPLS) RSVP-TE) and ITU-T Recommendation [G.7713.2].
The ITU-T Recommendation uses codepoints allocated via associated
RFCs [RFC 3474, RFC 3476]. Two basic interworking
scenarios are discussed.
G.7713.2 was intended to use the same basic mechanisms as and
to be backwards compatible to RFC 3473 when using RFC 3473 as
an Interior Network-Network Interface (I-NNI) protocol. Some
objects are required to be carried transparently, but are
allocated codepoints from the range for transparent forwarding
of unrecognized objects in accordance with existing RSVP.
The mechanisms described in this document are applicable to
any types of interfaces common to RFC 3473 and Recommendation
G.7713.2, esp. time-division multiplexed, lambda or
fiber switching interfaces.
L. Ong et al 1
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
In addition, the reader is assumed to be familiar with the
terminology used in [RFC-3471] and [RFC-3473].
3. Introduction
This document defines interworking procedures between [RFC 3473]
(Generalized MPLS (GMPLS) RSVP-TE) and ITU-T Recommendation [G.7713.2].
G.7713.2 codepoint allocation is documented in [RFC 3474] (GMPLS
RSVP-TE Usage and Extensions for ASON) signaling. The terms I-NNI
(Internal Network-Network Interface) and E-NNI (External Network-
Network Interface) are taken from ITU-T Recommendation [G.8080].
It should be noted that some interworking procedures described
have been implemented by multiple parties, although further
interoperability testing may be needed.
3.1 ASON Model
It is impossible to understand the extensions defined in G.7713.2
without also understanding the underlying ASON network model. The
ASON model allows a carrier network to consist of multiple domains,
consistent with the architecture of transport networks defined in
ITU-T Recommendation G.805 [G.805]. Client devices may attach to
the network at the User-Network Interface (UNI) reference point,
while peer-level domains meet at the Network-Network Interface
(NNI) reference point.
Each transport layer is considered separately as a layer network.
A layer network can be recursively partitioned into subnetworks,
which partitioning is based on network policy. Subnetworks are
defined to be completely contained within higher level subnetworks.
Transport networks typically do not have a single backbone, and
regulatory concerns may affect the partitioning of the network and
the routing of calls across the network.
Each subnetwork or domain may utilize a different protocol or even
different control architecture (e.g., one domain may use distributed
control while another peer domain may use centralized control). The
control protocols used across the NNI reference point are required
to be independent of the protocol used within the domains.
Figure 1 shows an abstract representation of an ASON network model.
L. Ong et al 2
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
---------- /---------\
//// \\\\ //// \\\\
-- | +--+ +--+ | | +--+ +--+ | --
| |:::::::| |------| |===============| |---| |::::::::::| |
-- | +--+ +--+ | | +--+ +--+ | --
\\\\ ||/// \\\\ ////
---------|| \---------/
Domain 1 || Domain 2
:: UNI ||
== E-NNI /-++--------\
-- I-NNI //// || \\\\
| +--+ +--+ | --
| | |---| |:::::::::::| |
| +--+ +--+ | --
\\\\ ////
\-----------/ Domain 3
Figure 1: ASON Network Example
3.2 Use of Call vs. Connection Concept
The ASON model employs the concept of a call to which zero or
more connections may be associated. In signalling protocols,
it is useful to distinguish between attributes that are call
related versus connection related because connection handling
entities in the network generally do not have to understand or
deal with call objects. The three new objects that RFC3474 and
RFC3476 introduce are all call objects. Having distinguished
between call and connection objects, TLVs should be designed so
that they do not mix call and connection objects. This makes
it easier for entities that only deal with connections as just
mentioned.
3.3 Analysis of G.7713.2 Extensions to RFC 3473
Given the requirements of ASON on call and connection control,
which are documented in more detail in ITU-T Recommendation G.7713
[G.7713], a limited number of extensions were made to the base
RSVP-TE signaling defined in RFC 3473. This section analyzes
the impact of these extensions.
3.3.1 Overall Extent of Changes
Messages: No new messages were defined in G.7713.2. Use
of some messages was considered not necessary
as discussed in section 3.3.2.
Objects: Two new objects are used in G.7713.2, the Gen_UNI
object defined in the OIF UNI, and a Call_ID object.
L. Ong et al 3
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
In addition, the Call_OPS object is defined in an
Appendix of G.7713.2.
(3 out of approximately 20-25 objects used in GMPLS)
C-Types: New C-Types were added for UNI and ENNI Session,
plus 5 new C-Types within G_UNI and 2 within Call_ID.
(11 out of approximately 80 or so used in GMPLS)
Procedures: The main changes to procedures was the elimination
of ResvErr and ResvTear, discussed below in section
3.3.2.
New object and C-Type codepoints are allocated in [RFC 3474, 3476].
3.3.2 ResvTear/RevErr
Concern has been raised as to whether a problem is introduced
because the ResvTear and ResvErr messages are not used in
G.7713.2 (sometimes called the "fatal flaw"). The procedures
supported by ResvTear and ResvErr were felt to be inconsistent with the
desired behavior of connection establishment in transport
networks, as they result in a requirement for exchange of
multiple messages in order to teardown the connection in
case of failure during connection setup.
ResvTear and ResvErr allow the exchange of error information
without teardown of the connection, however no case needing
this function has been identified in the call/connection
control requirements for ASON [G.7713]. If such a case
is identified in the future the associated procedures can
be added as an extension to G.7713.2.
It should be noted that no protocol violation occurs if a
ResvTear or ResvErr generates PathTear in the opposite
direction, as the protocol allows for this case. In
particular, ResvTear and ResvErr can be used within a
domain, so long as the interworking point at the edge of
the domain supports the appropriate interworking behavior.
3.3.3 Use of Non-standard objects
As discussed above, the new objects defined for G.7713.2 are
the G_UNI, Call_OPS and Call_ID, all of which are transparent
except at the terminating tunnel endpoint, based on the
codepoint range assigned for the objects.
L. Ong et al 4
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
3.3.4 Duplication of standard objects/procedures
As far as is known, the only duplication of procedures may
occur with SPC services, where RFC 3473 is not clear about
support of specification of an egress label. This issue is
now being addressed via a supplementary document.
However, the use of an SPC_Label subobject within the G_UNI
object has some advantages over the use of the ERO for this
purpose, esp. that ERO may not always be allowed across an
administrative boundary, whereas G_UNI is carried transparently.
As a result, use of an SPC_Label subobject may avoid some
error cases for the SPC service. In addition, SPC_Label
unambiguously identifies the type of service being supported
for the call, whereas an egress label specification within
the ERO could be a result of either an originating UNI request
or an SPC service request.
3.3.5 New Session objects
Concern has been raised that the incorporation of new Session
object C-Types for UNI and ENNI causes a backwards compatibility
issue with RFC 3473. Actually the reverse is true: the use
of specific C-Types for UNI and ENNI allow the receiving entity
to unambiguously distinguish when signaling received is for a
G.7713.2 UNI or ENNI interface. Such signaling received at a
RFC 3473 interface will be rejected due to the unrecognized
Session C-Type.
When used as an I-NNI protocol, G.7713.2 uses the same Session
object format and C-Type as RFC 3473 and functions in the same
way, i.e., the Session object value is not changed as it
traverses INNI reference points.
3.3.6 Terminology confusion
Some terminology confusion has been suggested and should
be clarified by further discussion.
3.3.7 Addressing
Concern has been raised that the introduction of the TNA
subobjects in G_UNI will require every system to be able
to process different types of addresses and address formats.
L. Ong et al 5
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
However, the TNA subobject, as a content of the G_UNI object,
is only processed at tunnel endpoints, and the choice of
address formats supported will be an option of the carrier.
A similar situation occurs in IP with the understanding of
exterior addresses. Only boundary nodes are required to
support routing based on such addresses, not all nodes.
It was noted that Ipv6 includes a mechanism for support of
NSAP format addresses. This could potentially be used to
eliminate one sub-type of the TNA, noting that this would not
affect the actual processing of addresses required, only
the manner of carrying them.
3.3.8 SPC Services
Discussed in section 3.2.4 above.
3.3.9 Session paradigm
Concern has been raised that the use of the multi-session
approach to RSVP-TE connection control violates basic
paradigms of RSVP. In the modeling of the Session object,
ITU-T have treated this as a connection-related identifier.
Using the separation of call and connection control, an end-
to-end call consists of potentially multiple concatenated
call segments. In the same way, each call segment may have
associated connection segments, hence the Session object
would contain the destination endpoint for that connection
segment, rather than the call endpoint.
While this may be incompatible with some implementations of
RSVP, the necessary information to identify a connection is
still present using the combination of TNA and Session object.
A possible mechanism to support implementations that rely
solely on the Session object is to use a unique value of the
extended tunnel ID within the Session object in order to
distinguish between connection segments, as described in
[RFC 3209].
L. Ong et al 6
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
3.3.10 Backwards Compatibility
Concerns have been raised as to the backwards compatibility of
G.7713.2 to RFC 3473. It should first be pointed out that
backwards compatibility to RFC 3473 was not a primary goal of the
work on ASON signaling, although it may be a more important goal
for work in IETF. G.7713.2 I-NNI can be deployed in a network of
nodes supporting RFC 3473 without requiring some interworking.
However, G.7713.2 UNI or E-NNI deliberately cannot.
This being said, G.7713.2 does support the three principles of
backwards compatibility identified in [RSVP-ASON]:
1) pre-ASON connections supported unchanged - this is true, as
G.7713.2 is only used at the UNI or E-NNI boundaries for a
domain relying on RFC 3473 as its I-NNI.
2) transit switches do not need to be upgraded to support new
functionality - this is true, as transit switches are only
required to pass the G_UNI and Call_ID objects transparently,
which will naturally occur based on the codepoint range.
3) a message received at a non-capable switch will be rejected -
for the UNI and ENNI interfaces this is true due to the use of
distinct C-Types for UNI and ENNI Session objects. Since these
C-Types are not recognized by a switch that does not support a
G.7713.2-based interface, the switch will reject the message,
with no way to process the unrecognized Session object type.
4. Interworking Specifications
The 3473-3474 interworking scenario occurs where a 3473 Overlay
interface is supported by either an RFC 3474 network or
a node with a 3473 Overlay interface is connected across
multiple domains using RFC 3474 at the E-NNI. This is shown
in Figures 2 and 3.
L. Ong et al 7
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
/----------\
//// \\\\
+---+ |+---+ +---+ +---+ +---+
| A |---------+-| X |---| Y |---| Z |+--------| C |
+---+ |+---+ +---+ +---+ +---+
RFC 3473 \\\\ //// RFC 3473
Overlay \----------/ Overlay
RFC 3474
I-NNI
Figure 2: 3473-3474 Interworking Case 1
+---+ +----+ +----+ +---+
| A |-----------| N1 |-----------| N2 |----------| C |
+---+ +----+ +----+ +---+
RFC 3473 RFC 3474 RFC 3473
Overlay E-NNI Overlay
Figure 3: 3473-3474 Interworking Case 2
These interworking cases may occur, for example, where
networks supporting RFC 3474 internally or at the E-NNI
interface to neighboring networks also support 3473 Overlay
to an IP client system.
The 3474-to-3473 interworking case is where a network using
RFC 3473 internally supports RFC 3474 interfaces at its border
nodes, as shown in Figure 4 below. In this case, RFC 3474
is supported across an RFC 3473 network or domain.
L. Ong et al 8
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
-------------
//// \\\\
// \\
+---+ +---+ +---+ +---+ +---+
| A |----------+| X |------| Y |------| Z |+----------| C |
+---+ +---+ +---+ +---+ +---+
\\ //
RFC 3474 \\\\ //// RFC 3474
UNI/NNI ------------- UNI/NNI
RFC 3473
I-NNI
Figure 4: 3474-to-3473 Interworking
This may be a typical application, for example, if the client
nodes A and C are not IP nodes or are identified by non-IP
addresses. RFC 3474 supports a client address (TNA) which is
separate from the 3473 addressing range and can convey non-IP
address formats such as NSAP. It also allows full overlap of
the client address range with the address range used in the
network, since separate objects are used for each.
The interworking point between 3474 and 3473 is required to
perform resolution of the TNA to the corresponding destination
node in the 3473 network.
3.3 Mapping of General 3474 Capabilities
RFC 3474 also identifies four specific requirements generating
the extensions defined:
a) support for call and connection separation
b) support for soft permanent connection
c) support for extended restart capabilities
d) additional error codes/values
As RFC 3473 does not support call and connection separation
or soft permanent connection, there are currently no additional
interworking requirements beyond transparent transport of
related objects (see 5.4). However, future study may be required
for support of features such as a call with no connections.
(c) is a local procedure and has no interworking implications
(d) is strictly a support item for the preceding requirements.
L. Ong et al 9
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
5. Procedures for 3473-3474 Interworking
5.1 Interworking of Session Object
For RFC 3473, the Session Object contains the tunnel endpoint
address, i.e., in Figure 2 the IP address of node C. For RFC
3474, which treats the tunnel as a concatenation of tunnels
linking multiple domains and domain boundaries, the Session
Object contains the endpoint of the local tunnel, i.e., in
Figure 2 the 3474 Session Object created by Node X would carry
the address of Node Z as the local tunnel endpoint.
For interworking purposes, the node receiving RFC 3473 RSVP
must map the tunnel endpoint address of the Session Object
into the Destination TNA sub-object of the GENERALIZED_UNI
object that is defined in RFC 3476 and used in 3474, since this
carries the end-to-end tunnel endpoint. That ingress node
then generates an appropriate RFC 3474 Session Object.
At the egress RFC 3474 node, the RFC 3473 Session Object
must be regenerated from the TNA and passed across the terminating
RFC 3473 interface to the destination client.
5.2 Interworking of Sender_Template
For RFC 3473, the Sender_Template contains the tunnel sender,
i.e., in Figure 2 the IP address of node A. For RFC 3474, the
Sender_Template contains the sender of the local tunnel, i.e.,
in Figure 1 the address of Node X at the X-Y interface.
For interworking purposes, the node receiving the RFC 3473
message must map the Sender_Template address into the Source
TNA sub-object of the GENERALIZED_UNI object from 3476, which
carries the corresponding information in RFC 3474/3476.
At the egress interface, the egress node uses the Source TNA
to regenerate the Sender_Template tunnel sender address.
5.3 Response Messages
The inverse mapping is required for messages sent from the
tunnel endpoint back to the tunnel source, before the
corresponding message is sent across the RFC 3473 interface
to the end-to-end tunnel source.
5.4 Other Objects
Other objects are unchanged in their significance between
RFC 3473 and RFC 3474.
L. Ong et al 10
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
6. Procedures for 3474-3473 Interworking
6.1 Addressing
One significant difference between RFC 3474 and RFC 3473 is
in the use of identifiers or address objects. RFC 3474
creates a separate client interface address using the TNA
(Transport Network-Assigned Address), which is a globally
unique identifier that may use Ipv4, Ipv6 or NSAP formats.
It should be noted that a common application for RFC 3474
may be for the access of systems that do not support IP
addressing. In this case, the end-to-end tunnel source/endpoint
may use non-IP addresses that cannot be supported by RFC
3473 objects. RFC 3474-3473 interworking would get around
this issue by carrying the actual tunnel source/endpoint
identifiers in a separate object and using IP format identifiers
within the 3473 domain.
6.2 Interworking of Session Object
The ingress node (i.e., node X of Figure 3)
maps the Destination TNA sub-object found in the received
GENERALIZED_UNI object into the IP address of the local
tunnel endpoint within the 3473 domain, i.e., node Z of
Figure 4. This is then used in the RFC 3473 Session object
sent to other nodes within the 3473 domain.
The GENERALIZED_UNI object is otherwise passed unchanged
across the 3473 domain. It is passed transparently at
nodes that support RFC 3473 only.
The egress RFC 3473 node (i.e., node Z of Figure 3)
then uses the Destination TNA sub-object to determine
the destination client interface.
6.3 Interworking of the Sender_Template
The ingress node is itself the local
tunnel source within the 3473 domain, and therefore puts
its own IP address in the RFC 3473 Sender_Template object.
6.4 Other Objects
Other objects may be received at the 3474/3473 interface,
esp. the Call_ID and Call_OPS objects defined in RFC 3474.
These are passed transparently across the 3473 domain.
L. Ong et al 11
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
7. Evolution Considerations
If the additional requirements that generated RFC 3474 are
accepted to be requirements that 3473 networks must also
support, interworking can be simplified by incorporating
protocol extensions from RFC 3474 that provide needed
functions, e.g., the Call_ID object, rather than attempting
to duplicate these functions in alternative ways.
8. Informative References
[RFC 3209] RSVP-TE
[RFC 3473] RSVP-TE Extensions for GMPLS
[RFC 3474] RSVP-TE Usage and Extensions for ASON
[RFC 3476] LDP and RSVP-TE Extensions for Optical UNI
Signaling
[G.7713.2] ITU-T Recommendation G.7713.2, "Distributed Call
and Connection Management: Signalling Mechanism Using GMPLS
RSVP-TE"
[G.8080] ITU-T Recommendation G.8080, "Architecture for the
automatically switched optical network (ASON)"
[G.805] ITU-T Recommendation G.805, "Generic functional
architecture of transport networks"
[G.7713] ITU-T Recommendation G.7713/Y.1704 (2001), "Distributed
Call and Connection Management (DCM)"
[UNI] OIF Implementation Agreement OIF-UNI-01.0, "User Network
Interface (UNI) 1.0 Signaling Specification", October 2001
9. Acknowledgements
The authors would like to thank Erning Ye, Zhi-Wei Lin, Nic Larkin,
Saikrishna Kotha and Manohar Ellanti for their comments and suggestions.
10. Author's Addresses
L. Ong J. Sadler
Ciena Tellabs
5965 Silver Creek Valley Rd 1415 W. Diehl Road
San Jose, CA 95138 Naperville, IL 60563
lyong@ciena.com jonathan.sadler@tellabs.com
E. Varma D. Pendarakis
Lucent IBM Research
101 Crawfords Corner Rd 30 Saw Mill River Rd
Holmdel, NJ 07733 Hawthorne, NY 10532
evarma@lucent.com dimitris@us.ibm.com
S. Shew
PO Box 3511 Station C
Ottawa ON K1Y 2H7
sdshew@nortelnetworks.com
L. Ong et al 12
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
Appendix A
Analysis of RFC 3474 Backwards Compatibility
Draft-ietf-ccamp-gmpls-ason-reqts-04.txt identifies three basic
requirements for backwards compatibility:
1)in a mixed network of nodes, it must be possible to set up
conventional connections. Use of any extensions must not perturb
existing conventional connections.
2) when transit nodes are in the path of a call/connection, extensions
must allow transit nodes to participate by passing information unmodified.
3) when a transit node or egress node must support a new function but
does not, extensions should be capable of being rejected in a way that
is not detrimental to the network as a whole.
The extensions defined in RFC 3474/ITU-T G.7713.2 satisfy the three
conditions as can be seen in the following:
A.1 Conventional Connections
In the model of RFC 3474/ITU G.7713.2, RFC 3474 may be used to support
an E-NNI interface or UNI interface to a network of RFC 3473 nodes.
Within the network of RFC 3473 nodes, conventional connections may
be set up without change. Connections between a source RFC 3474
node and destination RFC 3474 node do not perturb existing connections.
Border nodes supporting an RFC 3474 E-NNI or UNI interface may continue
to support origination, termination or transit of connections between
RFC 3473 source and destination nodes as a matter of node implementation
and carrier deployment.
A.2 Transit Nodes
As discussed in the interworking procedures above, transit nodes are
not required to implement extensions in order to support connections
between RFC 3474 source and destination as the extension objects are
in the range that are passed transparently by transit nodes.
The extension objects defined in RFC 3474 are only processed at the
source and destination endpoints of a particular LSP tunnel.
A.3 Rejection
Signaling using G.7713.2/RFC 3474 will utilize the UNI or ENNI
Session Object C-Type when used at the borders of a domain that
is strictly RFC 3473-based. Signaling messages
received incorrectly at an RFC 3473 interface will be rejected
due to the Session object format being unrecognized.
L. Ong et al 13
draft-ong-ccamp-3473-3474-iw-01.txt February 2004
Expires September 2004
Full Copyright Statement
"Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.