draft-ietf-ccamp-gmpls-vcat-lcas-02.txt   draft-ietf-ccamp-gmpls-vcat-lcas-03.txt 
CCAMP Working Group G. Bernstein (ed.) CCAMP Working Group G. Bernstein (ed.)
Internet Draft Grotto Networking Internet Draft Grotto Networking
Updates: RFC 3946 D. Caviglia Updates: RFC 3946 D. Caviglia
Category: Standards Track Ericsson Category: Standards Track Ericsson
Expires: September 2007 R. Rabbat Expires: April 2008 R. Rabbat
Google Google
H. van Helvoort H. van Helvoort
Huawei Huawei
March 30, 2007 October 3, 2007
Operating Virtual Concatenation (VCAT) and the Link Capacity Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
Switching (GMPLS) Switching (GMPLS)
draft-ietf-ccamp-gmpls-vcat-lcas-02.txt draft-ietf-ccamp-gmpls-vcat-lcas-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 30, 2007. This Internet-Draft will expire on October 3, 2007.
Abstract Abstract
This document describes requirements for, and use of, the Generalized This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction Multi-Protocol Label Switching (GMPLS) control plane in conjunction
with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS) mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to the Optical Transport multiplex group. These techniques apply to Optical Transport Network
Network (OTN), Synchronous Optical Network (SONET), Synchronous (OTN), Synchronous Optical Network (SONET), Synchronous Digital
Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.
signals.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Revision History...............................................3 2. Revision History...............................................3
2.1. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02..........3
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4 2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01..........3
2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00..........4
3. VCAT/LCAS Scenarios and Specific Requirements..................4 3. VCAT/LCAS Scenarios and Specific Requirements..................4
3.1. VCAT/LCAS Interface Capabilities..........................4 3.1. VCAT/LCAS Interface Capabilities..........................4
3.2. Member Signal Configuration Scenarios.....................4 3.2. Member Signal Configuration Scenarios.....................4
3.3. VCAT Operation With or Without LCAS.......................5 3.3. VCAT Operation With or Without LCAS.......................5
4. GMPLS Mechanisms in Support of VCGs............................6 4. GMPLS Mechanisms in Support of VCGs............................6
4.1. VCGs Composed of a Single Co-Signaled Member Set..........7 4.1. VCGs Composed of a Single Co-Signaled Member Set..........7
4.1.1. One-shot VCG Setup with Co-Signaled Members..........7 4.1.1. One-shot VCG Setup with Co-Signaled Members..........7
4.1.2. Incremental VCG Setup with Co-Signaled Members.......7 4.1.2. Incremental VCG Setup with Co-Signaled Members.......8
4.1.3. Procedure for VCG Reduction by Removing a Member.....8 4.1.3. Procedure for VCG Reduction by Removing a Member.....8
4.1.4. Removing Multiple VCG Members in One Shot............8 4.1.4. Removing Multiple VCG Members in One Shot............9
4.1.5. Teardown of Whole VCG................................9 4.1.5. Teardown of Whole VCG................................9
4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9 4.2. VCGs Composed of Multiple Co-Signaled Member Sets.........9
4.2.1. Signaled VCG Layer Information.......................9 4.2.1. Signaled VCG Layer Information......................10
4.2.2. Procedures for VCG Control with Multiple Co-signaled 4.2.2. Procedures for VCG Control with Multiple Co-signaled
Member Sets................................................10 Member Sets................................................10
4.3. Member Sharing -- Multiple VCGs per Call.................11 4.3. Member Sharing -- Multiple VCGs per Call.................11
5. IANA Considerations...........................................12 5. IANA Considerations...........................................13
6. Security Considerations.......................................12 6. Security Considerations.......................................13
7. Contributors..................................................13 7. Contributors..................................................14
8. Acknowledgments...............................................13 8. Acknowledgments...............................................14
9. References....................................................14 9. References....................................................15
9.1. Normative References.....................................14 9.1. Normative References.....................................15
9.2. Informative References...................................14 9.2. Informative References...................................15
Author's Addresses...............................................15 Author's Addresses...............................................16
Intellectual Property Statement..................................15 Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16 Disclaimer of Validity...........................................17
Copyright Statement..............................................16 Copyright Statement..............................................17
Acknowledgment...................................................16 Acknowledgment...................................................17
1. Introduction 1. Introduction
The Generalized Multi-Protocol Label Switching (GMPLS) suite of The Generalized Multi-Protocol Label Switching (GMPLS) suite of
protocols allows the automated control of different switching protocols allows for the automated control of different switching
technologies including SONET/SDH and OTN. This document describes technologies including Synchronous Optical Network (SONET),
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)
and Plesiochronous Digital Hierarchy (PDH). This document describes
extensions to RSVP-TE to support the Virtual Concatenation (VCAT) extensions to RSVP-TE to support the Virtual Concatenation (VCAT)
layer 1 inverse multiplexing mechanism that has been standardized for layer 1 inverse multiplexing mechanism that has been standardized for
SONET, SDH, OTN and PDH technologies along with its companion Link SONET, SDH, OTN and PDH technologies along with its companion Link
Capacity Adjustment Scheme (LCAS). Capacity Adjustment Scheme (LCAS).
VCAT is a TDM oriented byte striping inverse multiplexing method that VCAT is a TDM oriented byte striping inverse multiplexing method that
works with a wide range of existing and emerging TDM framed signals, works with a wide range of existing and emerging TDM framed signals,
including very high bit rate OTN and SDH/SONET signals. Other than including very high bit rate OTN and SDH/SONET signals. Other than
member signal skew compensation layer 1 inverse multiplexing member signal skew compensation this layer 1 inverse multiplexing
mechanism add minimal additional signal delay. VCAT permits the mechanism adds minimal additional signal delay. VCAT enables the
selection of an optimal signals size, extracting bandwidth from mesh selection of an optimal signal bandwidth (size), extraction of
networks and when combined with LCAS hitless dynamic resizing of bandwidth from a mesh network, and, when combined with LCAS, hitless
bandwidth and fast graceful degradation in the presence of network dynamic resizing of bandwidth and fast graceful degradation in the
faults. To take full advantage of VCAT/LCAS functionality extensions presence of network faults. To take full advantage of VCAT/LCAS
to GMPLS signaling are given that enable the setup of diversely functionality extensions to GMPLS signaling are given that enable the
routed circuits that are members of the same VCAT group. setup of diversely routed circuits that are members of the same VCAT
group.
2. Revision History 2. Revision History
2.1. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01 2.1. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-02
o Grammar and punctuation fixes. Updated references with newly
published RFCs.
2.2. Changes from draft-ieft-ccamp-gmpls-vcat-lcas-01
o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint" o Changed section 3.1 from "Multiple VCAT Groups per GMPLS endpoint"
to "Multiple VCAT Groups per Interface" to improve clarity. to "VCAT/LCAS Interface Capability" to improve clarity.
o Changed terminology from "component" signal to "member" signal o Changed terminology from "component" signal to "member" signal
where possible (not quoted text) to avoid confusion with link where possible (not quoted text) to avoid confusion with link
bundle components. bundle components.
o Added "Dynamic, member sharing" scenario. o Added "Dynamic, member sharing" scenario.
o Clarified requirements with respect to scenarios and the LCAS and o Clarified requirements with respect to scenarios and the LCAS and
non-LCAS cases. non-LCAS cases.
skipping to change at page 4, line 9 skipping to change at page 4, line 19
VCAT endpoints to support required scenarios. VCAT endpoints to support required scenarios.
o Added text to describe: co-signaled, co-routed, data plane LSP, o Added text to describe: co-signaled, co-routed, data plane LSP,
control plane LSP and their relationship to the VCAT/LCAS control plane LSP and their relationship to the VCAT/LCAS
application. application.
o Change implementation mechanism from one based on the Association o Change implementation mechanism from one based on the Association
object to one based on "Call concepts" utilizing the Notify object to one based on "Call concepts" utilizing the Notify
message. message.
2.2. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00 2.3. Changes from draft-ietf-ccamp-gmpls-vcat-lcas-00
o Updated reference from RFC3946bis to issued RFC4606 o Updated reference from RFC3946bis to issued RFC4606
o Updated section 3.2 based on discussions on the mailing list o Updated section 3.2 based on discussions on the mailing list
3. VCAT/LCAS Scenarios and Specific Requirements 3. VCAT/LCAS Scenarios and Specific Requirements
There are a number of specific requirements for the support of There are a number of specific requirements for the support of
VCAT/LCAS in GMPLS that can be derived from the carriers' VCAT/LCAS in GMPLS that can be derived from the carriers'
application-specific demands for the use of VCAT/LCAS and from the application-specific demands for the use of VCAT/LCAS and from the
skipping to change at page 4, line 41 skipping to change at page 5, line 8
3.2. Member Signal Configuration Scenarios 3.2. Member Signal Configuration Scenarios
We list in this section the different scenarios. Here we use the We list in this section the different scenarios. Here we use the
term "VCG" to refer to the entire VCAT group and the terminology term "VCG" to refer to the entire VCAT group and the terminology
"set" and "subset" to refer to the collection of potential VCAT group "set" and "subset" to refer to the collection of potential VCAT group
member signals. member signals.
o Fixed, co-routed: A fixed bandwidth VCG, transported over a co- o Fixed, co-routed: A fixed bandwidth VCG, transported over a co-
routed set of member signals. This is the case where the intended routed set of member signals. This is the case where the intended
bandwidth of the VCG does not change and all member signals follow bandwidth of the VCG does not change and all member signals follow
the same route and minimize differential delay. The intent here the same route to minimize differential delay. The intent here is
is the capability to allocate an amount of bandwidth close to that the capability to allocate an amount of bandwidth close to that
required at the client layer. required at the client layer.
o Fixed, diversely routed: A fixed bandwidth VCG, transported over o Fixed, diversely routed: A fixed bandwidth VCG, transported over
at least two diversely routed subsets of member signals. In this at least two diversely routed subsets of member signals. In this
case, the subsets are link-disjoint over at least one link of the case, the subsets are link-disjoint over at least one link of the
route. The intent here is more efficient use of network resources route. The intent here is more efficient use of network
(no unique route has the required bandwidth). resources, e.g., no unique route has the required bandwidth.
o Fixed, member sharing: A fixed bandwidth VCG, transported over a o Fixed, member sharing: A fixed bandwidth VCG, transported over a
set of member signals that are allocated from a common pool of set of member signals that are allocated from a common pool of
available member signals without requiring member connection available member signals without requiring member connection
teardown and setup. teardown and setup.
o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or
decreased via the addition or removal of member signals), decreased via the addition or removal of member signals),
transported over a co-routed set of members. The intent here is transported over a co-routed set of members. The intent here is
dynamic resizing and resilience of bandwidth. dynamic resizing and resilience of bandwidth.
skipping to change at page 6, line 34 skipping to change at page 6, line 43
1. VCG member -- This is an individual data plane signal of one of the 1. VCG member -- This is an individual data plane signal of one of the
permitted SDH, SONET, OTN or PDH signal types. permitted SDH, SONET, OTN or PDH signal types.
2. Co-signaled member set -- One or more VCG members (or potential 2. Co-signaled member set -- One or more VCG members (or potential
members) set up via the same control plane signaling exchange. Note members) set up via the same control plane signaling exchange. Note
that all members in a co-signaled set follow the same route. that all members in a co-signaled set follow the same route.
3. Co-routed member set - One or more VCG members that follow the same 3. Co-routed member set - One or more VCG members that follow the same
route. Although VCG members may follow the same path, this does not route. Although VCG members may follow the same path, this does not
imply that they we co-signaled. imply that they were co-signaled.
4. Data plane LSP -- for our purposes here this is equivalent to an 4. Data plane LSP -- for our purposes here, this is equivalent to an
individual VCG member. individual VCG member.
5. Control plane LSP -- A control plane entity that can control 5. Control plane LSP -- A control plane entity that can control
multiple data plane LSPs. For our purposes here this is equivalent multiple data plane LSPs. For our purposes here this is equivalent
to our co-signaled member set. to our co-signaled member set.
Section 4.1 is included for informational purposes only. It Section 4.1 is included for informational purposes only. It
describes existing GMPLS procedures that support a single VCG describes existing GMPLS procedures that support a single VCG
composed of a single co-signaled member set. composed of a single co-signaled member set.
Section 4.2 describes new procedures to support VCGs composed of more Section 4.2 describes new procedures to support VCGs composed of more
that one co-signaled member sets. This includes the important than one co-signaled member sets. This includes the important
application of a VCG composed of diversely routed members. Where application of a VCG composed of diversely routed members. Where
possible it reuses applicable existing procedures from section 4.1. possible it reuses applicable existing procedures from section 4.1.
4.1. VCGs Composed of a Single Co-Signaled Member Set 4.1. VCGs Composed of a Single Co-Signaled Member Set
Note that this section is for informational purposes only. Note that this section is for informational purposes only.
The existing signaling GMPLS signaling protocols support a VCG The existing GMPLS signaling protocols support a VCG composed of a
composed of a single co-signaled member set. Setup using the NVC single co-signaled member set. Setup using the NVC field is explained
field as explained in section 2.1 of [RFC4606]. In this case, one in section 2.1 of [RFC4606]. In this case, one single control plane
single control plane LSP is used in support of the VCG. LSP is used in support of the VCG.
There are two options for setting up the VCG, depending on hardware There are two options for setting up the VCG, depending on hardware
capability, or management preferences: one-shot setup and incremental capability, or management preferences: one-shot setup and incremental
setup. setup.
The following sections explain the procedure based on an example of The following sections explain the procedure based on an example of
setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v
SONET VCAT group). SONET VCAT group).
4.1.1. One-shot VCG Setup with Co-Signaled Members 4.1.1. One-shot VCG Setup with Co-Signaled Members
skipping to change at page 9, line 35 skipping to change at page 9, line 46
can be initiated and terminated between the same nodes and can be initiated and terminated between the same nodes and
their corresponding components can then be associated together their corresponding components can then be associated together
(i.e., virtually concatenated). (i.e., virtually concatenated).
The setup of diversely routed VCG members requires multiple co- The setup of diversely routed VCG members requires multiple co-
signaled VCG member sets, i.e., multiple control plane LSPs. signaled VCG member sets, i.e., multiple control plane LSPs.
To support a VCG with multiple co-signaled VCG members sets requires To support a VCG with multiple co-signaled VCG members sets requires
being able to identify separate control plane LSPs with a single VCG being able to identify separate control plane LSPs with a single VCG
and exchange information pertaining to the VCG as a whole. This is and exchange information pertaining to the VCG as a whole. This is
very similar to the "Call" concept described in [CallDraft]. We can very similar to the "Call" concept described in [RFC4974]. We can
think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer
service that makes use of multiple lower layer (server) connections service that makes use of multiple lower layer (server) connections
that are controlled by one or more control plane LSPs. that are controlled by one or more control plane LSPs.
4.2.1. Signaled VCG Layer Information 4.2.1. Signaled VCG Layer Information
When a VCG is composed of multiple co-signaled member sets, none of When a VCG is composed of multiple co-signaled member sets, none of
the control plane LSP's signaling information can contain information the control plane LSP's signaling information can contain information
pertinent to the entire VCG. In this section we give a list of pertinent to the entire VCG. In this section we give a list of
information that should be communicated at what we define as the VCG information that should be communicated at what we define as the VCG
Call layer, i.e., between the VCG signaling endpoints. To Call layer, i.e., between the VCG signaling endpoints. To
accommodate this information additional objects or TLVs would need to accommodate this information additional objects or TLVs would need to
be incorporated into the Notify message as it is described for use in be incorporated into the Notify message as it is described for use in
call signaling in [CallDraft]. call signaling in [RFC4974].
VCG Call setup information signaled via the Notify message with the VCG Call setup information signaled via the Notify message with the
Call management bit (C-bit) set: Call management bit (C-bit) set:
1. Signal Type 1. Signal Type
2. Number of VCG Members 2. Number of VCG Members
3. LCAS requirements: 3. LCAS requirements:
skipping to change at page 11, line 25 skipping to change at page 11, line 35
LSPs (members). LSPs (members).
Note that when LCAS is not used or unavailable the VCG will be in an Note that when LCAS is not used or unavailable the VCG will be in an
unknown state between the time the VCG call level information is unknown state between the time the VCG call level information is
updated and the actual data plane LSPs are added or removed. updated and the actual data plane LSPs are added or removed.
4.3. Member Sharing -- Multiple VCGs per Call 4.3. Member Sharing -- Multiple VCGs per Call
To support the member sharing scenario of section 3.2. we allow To support the member sharing scenario of section 3.2. we allow
multiple VCGs within the context of the VCG Call defined here. This multiple VCGs within the context of the VCG Call defined here. This
is partially due to the requirement in reference [CallDraft] that is partially due to the requirement in reference [RFC4974] that LSPs
LSPs are associated with a single call over their lifetime. Hence we are associated with a single call over their lifetime. Hence we
propose using the VCG Call mechanism previously described to propose using the VCG Call mechanism previously described to
establish the common member pool for all the VCGs to be included in establish the common member pool for all the VCGs to be included in
the scope of this particular VCG Call. Note that the maximum number the scope of this particular VCG Call. Note that the maximum number
of VCGs per call is a key parameter to call acceptance or rejection of VCGs per call is a key parameter to call acceptance or rejection
since VCAT equipment typically puts limits on the total number of since VCAT equipment typically puts limits on the total number of
VCGs that can be simultaneously supported. VCGs that can be simultaneously supported.
To assign a data plane LSP to be a member of a particular VCG or to To assign a data plane LSP to be a member of a particular VCG or to
remove a data plane LSP from being a member of a particular VCG, remove a data plane LSP from being a member of a particular VCG,
requires additional VCG layer communications. LCAS [ITU-T-G.7042] requires additional VCG layer communications. LCAS [ITU-T-G.7042]
skipping to change at page 12, line 4 skipping to change at page 12, line 12
indicate which VCG out of multiple between a source and destination a indicate which VCG out of multiple between a source and destination a
member should belong. In particular, although, it seems that LCAS' member should belong. In particular, although, it seems that LCAS'
Group Identification (GID) bit should be useful for this purpose Group Identification (GID) bit should be useful for this purpose
reference [ITU-T-G.7042] specifically states: reference [ITU-T-G.7042] specifically states:
"The GID provides the receiver with a means of "The GID provides the receiver with a means of
verifying that all the arriving members originated verifying that all the arriving members originated
from one transmitter. The contents are pseudo- from one transmitter. The contents are pseudo-
random, but the receiver is not required to random, but the receiver is not required to
synchronize with the incoming stream." synchronize with the incoming stream."
In the following we sketch the outline of such a high level VCG layer In the following we sketch the outline of such a high level VCG layer
signaling procedure that could make use of the Notify message as in signaling procedure that could make use of the Notify message as in
reference [CallDraft]. reference [RFC4974].
After the VCG call has been established, a signaling endpoint of the After the VCG call has been established, a signaling endpoint of the
VCG call for would then: VCG call for would then:
1. Choose an identifier for each VCG that will use member signals 1. Choose an identifier for each VCG that will use member signals
from the common pool. Note that these identifiers only need to from the common pool. Note that these identifiers only need to
be unique with in the context of the VCG Call. be unique with in the context of the VCG Call.
2. Assign member signals from the common pool to each of the VCG 2. Assign member signals from the common pool to each of the VCG
utilizing the previously defined VCG IDs. Member signals are utilizing the previously defined VCG IDs. Member signals are
skipping to change at page 12, line 48 skipping to change at page 13, line 14
5. IANA Considerations 5. IANA Considerations
This document requests from IANA the assignment of ... (Don't know This document requests from IANA the assignment of ... (Don't know
yet what we may want) yet what we may want)
6. Security Considerations 6. Security Considerations
This document introduces a specific use of the Notify message and This document introduces a specific use of the Notify message and
admin status object for GMPLS signaling as originally specified in admin status object for GMPLS signaling as originally specified in
[CallDraft]. It does not introduce any new signaling messages, nor [RFC4974]. It does not introduce any new signaling messages, nor
change the relationship between LSRs that are adjacent in the control change the relationship between LSRs that are adjacent in the control
plane. The call information associated with diversely routed control plane. The call information associated with diversely routed control
plane LSPs, in the event of an interception may indicate that there plane LSPs, in the event of an interception may indicate that there
are members of the same VCAT group that take a different route and are members of the same VCAT group that take a different route and
may indicate to an interceptor that the VCG call desires increased may indicate to an interceptor that the VCG call desires increased
reliability. reliability.
Otherwise, this document does not introduce any additional security Otherwise, this document does not introduce any additional security
considerations. considerations.
skipping to change at page 14, line 23 skipping to change at page 15, line 23
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, December Digital Hierarchy (SDH) Control", RFC 4606, December
2005. 2005.
[CallDraft] D. Papadimitriou and A. Farrel, "Generalized MPLS [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS
(GMPLS) RSVP-TE Signaling Extensions in support of (GMPLS) RSVP-TE Signaling Extensions in Support of
Calls", draft-ietf-ccamp-gmpls-rsvp-te-call-04.txt, Calls", RFC 4974, August 2007.
January, 2007.
9.2. Informative References 9.2. Informative References
[ANSI-T1.105] American National Standards Institute, "Synchronous [ANSI-T1.105] American National Standards Institute, "Synchronous
Optical Network (SONET) - Basic Description including Optical Network (SONET) - Basic Description including
Multiplex Structure, Rates, and Formats", ANSI T1.105- Multiplex Structure, Rates, and Formats", ANSI T1.105-
2001, May 2001. 2001, May 2001.
[ITU-T-G.7042] International Telecommunications Union, "Link Capacity [ITU-T-G.7042] International Telecommunications Union, "Link Capacity
Adjustment Scheme (LCAS) for Virtual Concatenated Adjustment Scheme (LCAS) for Virtual Concatenated
 End of changes. 28 change blocks. 
59 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/