Network Working Group E. Roch
Internet Draft Nortel Networks
Intended status: Informational J. Sadler
Expires: April 2010 Tellabs
October 19, 2009
Signaling for Inverse Multiplexing Schemes via GMPLS using RSVP-TE
draft-roch-ccamp-gmpls-inv-mux-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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
This Internet-Draft will expire on April 19, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Roch and Sadler Expires April 19, 2010 [Page 1]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
Abstract
A set of requirements and a proposed implementation for the control
of the SONET/SDH inverse multiplexing capabilities known as VCAT/LCAS
is given in [CCAMP-VCAT]. However, implementations based on OIF
implementation agreements and their prototype extensions have
identified gaps in [CCAMP-VCAT]. This draft proposes a wider scoped
alternative implementation approach that addresses the requirements
of [CCAMP-VCAT] and additional requirements of independent setup of
the VCAT group and its members.
Table of Contents
1. Introduction...................................................2
2. Conventions....................................................2
3. Use Cases and Requirements.....................................3
4. Signaling Extensions...........................................3
4.1. Extension for IMG layer identification....................4
4.2. Extension for IMG bandwidth...............................4
5. Security Considerations........................................5
6. IANA Considerations............................................5
7. References.....................................................5
7.1. Normative References......................................5
8. Acknowledgments................................................6
1. Introduction
The Optical Internetworking Forum (www.oiforum.com) has demonstrated
signaling for inverse multiplexing in several of its worldwide
interoperability events in 2005, 2007 and 2009. The OIF demos
included signaling for Ethernet over VCAT control plane enabled
connections. The demos included separate call and connection
signaling for Ethernet, VCAT and STS-1/VC-4.
This is the model described in [LIAISON-291].
In order to perform the various interoperability events, some
experimental extensions were tested and included the use of the NVC
field of SONET/SDH SENDER_TSPEC in the VCAT layer signaling to
indicate that the RSVP signaling exchanged pertained to VCAT. This
approach, however, is not compatible with GMPLS implementations and
could only be used in this experimental setting.
2. Conventions
The following abbreviation is used in this document:
Roch and Sadler Expires April 19, 2010 [Page 2]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
IMG: Inverse Multiplexing Group
3. Use Cases and Requirements
In a scenario where several signals are inverse multiplexed together
to form an Inverse Multiplexing Group (IMG), it is possible that the
IMG is established by the control plane but that the IMG members are
not. Even in the case that the IMG members are control plane
established, the members might be separately administered and
policies may prevent signaling control information related to the IMG
to be exchanged in the IMG member signaling. This results in a
requirement to support independent signaling for the IMG and its
members. This is a gap in [CCAMP-VCAT] because it piggybacks the VCAT
call signaling CALL_ATTRIBUTES onto VCAT member signaling. If the IMG
members are provisioned or if it is control plane enabled but does
not allow piggybacking of IMG information onto its own signaling, it
is not possible to use the procedure described in [CCAMP-VCAT].
Business and/or regulatory requirements have caused the separation of
"advanced telecommunications service" entities from traditional
transport entities. The result of this has placed the management of
data equipment, e.g. Ethernet switches, into a separate group from
transport equipment. Given that the inverse multiplexing of a number
of TDM connections together to satisfy requirements of the "advanced
telecommunications service" organization is opaque to the transport
organization, the configuration of the VCAT group cannot be
piggybacked on the signaling for the TDM connections.
4. Signaling Extensions
This section proposes a solution where signaling for an IMG and its
members are performed independently, each requiring its own RSVP
session and associated messaging.
The IMG member signaling follows existing RSVP-TE based GMPLS
signaling for the corresponding member signal.
The IMG signaling is based on existing RSVP-TE based GMPLS signaling
described in [RFC3471] and [RFC3473] with the following
modifications:
- A mechanism to identify that RSVP-TE signaling is reserving member
resources for an IMG, described in this document.
- A more generic mechanism to specify the requested bandwidth,
described in this document.
Roch and Sadler Expires April 19, 2010 [Page 3]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
- A mechanism that allows an RSVP_HOP to include several sub-TLVs
for each direction, where each sub-TLV uniquely identifies one of
the members of the IMG. A suitable solution could reuse the
encoding from [MT_BDL].
4.1. Extension for IMG signaling identification
In order to identify that the signaling is related to an inverse
multiplexing group, there has to be an indication in the signaling
message. For example, a new Switching Type value could be defined for
the RSVP-TE Generalized Label Request [RFC3473][RFC3471].
A new switching type (TBD) for Inverse Multiplexing Capable is
defined.
Value Type
----- ----
TBD Inverse-Multiplex Capable (IMC)
4.2. Extension for IMG bandwidth
In order to identify the bandwidth for an IMG, a description of the
members and their numbers is necessary. A new IMG SENDER_TSPEC (Class
12, C-TYPE TBD)/FLOWSPEC (Class 9, C-TYPE TBD) is defined
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (Variable) | Class (12/9) | C-Type (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Number of Members |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type can take the following values, based on [CCAMP-VCAT]:
Value Type (Elementary Signal)
----- ------------------------
1 VT1.5 SPE / VC-11
2 VT2 SPE / VC-12
3 STS-1 SPE / VC-3
4 STS-3c SPE / VC-4
11 OPU1 (i.e., 2.5 Gbit/s
12 OPU2 (i.e., 10 Gbit/s)
13 OPU3 (i.e., 40 Gbit/s)
Roch and Sadler Expires April 19, 2010 [Page 4]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
21 T1 (i.e., 1.544 Mbps)
22 E1 (i.e., 2.048 Mbps)
23 E3 (i.e., 34.368 Mbps)
24 T3 (i.e., 44.736 Mbps)
5. Security Considerations
This document does not identify any security issues.
6. IANA Considerations
New Switching type for Inverse-Multiplex Capable (ICM).
New C-Type for SENDER_TSPEC/FLOWSPEC for IMG.
7. References
7.1. Normative References
[CCAMP-VCAT] Bernstein, G. (Editor), "Operating Virtual Concatenation
(VCAT) and the Link Capacity Adjustement Scheme (LCAS) with
Generalized Multi-Protocol Label Switching (GMPLS)", draft-
ietf-ccamp-gmpls-vcat-lcas-08.txt, July 2009.
[G.805] ITU-T Rec G.805, "Generic functional architecture of
transport networks", March 2000.
[G.8080] ITU-T Rec G.8080/Y.1304, "Architecture for the Automatically
Switched Optical Network (ASON)", June 2006.
[LIAISON-291] ITU-T SG15, "Response to IETF CCAMP WG LS (TD314/3) on
Notification of work in the IETF CCAMP working group",
November 2006.
[MT_BDL] Sadler, J. "Multiplier (MT) support over Bundled Links in
RSVP-TE", draft-sadler-ccamp-rsvp-mt-bundled-links-00.txt,
October 2009.
[RFC3471] Berger, L. "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC3471, January
2003.
[RFC3473] Berger, L. "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC3473, January 2003.
Roch and Sadler Expires April 19, 2010 [Page 5]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
8. Acknowledgments
The authors would like to thank the following OIF members for their
comments and support for this document:
Xihua Fu (ZTE Corporation)
Remi Theillaud (Marben Products)
This document was prepared using 2-Word-v2.0.template.dot.
Roch and Sadler Expires April 19, 2010 [Page 6]
Internet-Draft draft-roch-ccamp-gmpls-inv-mux October 2009
Authors' Addresses
Evelyne Roch
Nortel Networks
3500 Carling Avenue
Ottawa, ON K2H 8E9 Canada
Email: eroch@nortel.com
Jonathan Sadler
Tellabs
1415 W. Diehl Rd.
Naperville, IL 60565 USA
Email: jonathan.sadler@tellabs.com
Roch and Sadler Expires April 19, 2010 [Page 7]