draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt   draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Category: Experimental Attila Takacs (Ericsson) Category: Experimental Attila Takacs (Ericsson)
Expiration Date: October 29, 2008 Diego Caviglia (Ericsson) Expiration Date: May 17, 2009 Diego Caviglia (Ericsson)
Don Fedyk (Nortel) Don Fedyk (Nortel)
Julien Meuric (France Telecom) Julien Meuric (France Telecom)
April 29, 2008 November 17, 2008
GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt draft-ietf-ccamp-asymm-bw-bidir-lsps-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 October 29, 2008. This Internet-Draft will expire on May 17, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a method for the support of GMPLS Asymmetric This document defines a method for the support of GMPLS Asymmetric
Bandwidth Bidirectional Label Switched Paths (LSPs). The presented Bandwidth Bidirectional Label Switched Paths (LSPs). The presented
approach is applicable to any switching technology and builds on the approach is applicable to any switching technology and builds on the
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3 Packet Formats ............................................ 7 3 Packet Formats ............................................ 7
4 Compatibility ............................................. 8 4 Compatibility ............................................. 8
5 IANA Considerations ....................................... 8 5 IANA Considerations ....................................... 8
5.1 UPSTREAM_FLOWSPEC Object .................................. 8 5.1 UPSTREAM_FLOWSPEC Object .................................. 8
5.2 UPSTREAM_TSPEC Object ..................................... 9 5.2 UPSTREAM_TSPEC Object ..................................... 9
5.3 UPSTREAM_ADSPEC Object .................................... 9 5.3 UPSTREAM_ADSPEC Object .................................... 9
6 Security Considerations ................................... 9 6 Security Considerations ................................... 9
7 References ................................................ 9 7 References ................................................ 9
7.1 Normative References ...................................... 9 7.1 Normative References ...................................... 9
7.2 Informative References .................................... 10 7.2 Informative References .................................... 10
8 Authors' Addresses ........................................ 10 8 Authors' Addresses ........................................ 11
A. Appendix A: Alternate Approach Using ADSPEC Object ........ 11 A. Appendix A: Alternate Approach Using ADSPEC Object ........ 11
A.1. Applicability ............................................. 11 A.1. Applicability ............................................. 11
A.2. Overview .................................................. 12 A.2. Overview .................................................. 12
A.3. Procedures ................................................ 13 A.3. Procedures ................................................ 13
A.4. Compatibility ............................................. 13 A.4. Compatibility ............................................. 14
Full Copyright Statement .................................. 14 Full Copyright Statement .................................. 14
Intellectual Property ..................................... 14 Intellectual Property ..................................... 14
1. Introduction 1. Introduction
GMPLS, see [RFC3473], introduced explicit support for bidirectional GMPLS, see [RFC3473], introduced explicit support for bidirectional
Label Switched Paths (LSPs). The defined support matched the Label Switched Paths (LSPs). The defined support matched the
switching technologies covered by GMPLS, notably Time Division switching technologies covered by GMPLS, notably Time Division
Multiplexing (TDM) and lambdas, and specifically only supported Multiplexing (TDM) and lambdas, and specifically only supported
bidirectional LSPs with symmetric bandwidth allocation. Symmetric bidirectional LSPs with symmetric bandwidth allocation. Symmetric
skipping to change at page 5, line 39 skipping to change at page 5, line 39
formats. The class number of the UPSTREAM_FLOWSPEC object object is formats. The class number of the UPSTREAM_FLOWSPEC object object is
TBA by IANA (of the form 0bbbbbbb). TBA by IANA (of the form 0bbbbbbb).
2.1.1. Procedures 2.1.1. Procedures
The Path message of an asymmetric bandwidth bidirectional LSP MUST The Path message of an asymmetric bandwidth bidirectional LSP MUST
contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional
LSP formats and procedures defined in [RFC3473]. The C-Type of the LSP formats and procedures defined in [RFC3473]. The C-Type of the
UPSTREAM_FLOWSPEC Object MUST match the C-Type of the SENDER_TSPEC UPSTREAM_FLOWSPEC Object MUST match the C-Type of the SENDER_TSPEC
object used in the Path message. The contents of the object used in the Path message. The contents of the
UPSTREAM_FLOWSPEC Object MUST be constructed using a consistent UPSTREAM_FLOWSPEC Object MUST be constructed using a format and
format and procedures used to construct the FLOWSPEC object that will procedures consistent with those used to construct the FLOWSPEC
be used for the LSP, e.g., [RFC2210] or [RFC4328]. object that will be used for the LSP, e.g., [RFC2210] or [RFC4328].
Nodes processing a Path message containing an UPSTREAM_FLOWSPEC Nodes processing a Path message containing an UPSTREAM_FLOWSPEC
Object MUST use the contents of the UPSTREAM_FLOWSPEC Object in the Object MUST use the contents of the UPSTREAM_FLOWSPEC Object in the
upstream label and resource allocation procedure defined in Section upstream label and resource allocation procedure defined in Section
3.1 of [RFC3473]. Consistent with [RFC3473], a node that is unable 3.1 of [RFC3473]. Consistent with [RFC3473], a node that is unable
to allocate a label or internal resources based on the contents of to allocate a label or internal resources based on the contents of
the UPSTREAM_FLOWSPEC Object, MUST issue a PathErr message with a the UPSTREAM_FLOWSPEC Object, MUST issue a PathErr message with a
"Routing problem/MPLS label allocation failure" indication. "Routing problem/MPLS label allocation failure" indication.
2.2. UPSTREAM_TSPEC Object 2.2. UPSTREAM_TSPEC Object
skipping to change at page 6, line 20 skipping to change at page 6, line 20
by IANA (of the form 0bbbbbbb). by IANA (of the form 0bbbbbbb).
2.2.1. Procedures 2.2.1. Procedures
The UPSTREAM_TSPEC object describes the traffic flow that originates The UPSTREAM_TSPEC object describes the traffic flow that originates
at the egress. The UPSTREAM_TSPEC object MUST be included in any at the egress. The UPSTREAM_TSPEC object MUST be included in any
Resv message that corresponds to a Path message containing an Resv message that corresponds to a Path message containing an
UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object
MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object. MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object.
The contents of the UPSTREAM_TSPEC Object MUST be constructed using a The contents of the UPSTREAM_TSPEC Object MUST be constructed using a
consistent format and procedures used to construct the FLOWSPEC format and procedures consistent with those used to construct the
object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or
The contents of the UPSTREAM_TSPEC Object MAY differ from contents of [RFC4328]. The contents of the UPSTREAM_TSPEC Object MAY differ from
the UPSTREAM_FLOWSPEC object based on application data transmission contents of the UPSTREAM_FLOWSPEC object based on application data
requirements. transmission requirements.
When an UPSTREAM_TSPEC object is received by an ingress, the ingress When an UPSTREAM_TSPEC object is received by an ingress, the ingress
MAY determine that the original reservation is insufficient to MAY determine that the original reservation is insufficient to
satisfy the traffic flow. In this case, the ingress MAY issue a Path satisfy the traffic flow. In this case, the ingress MAY issue a Path
message with an updated UPSTREAM_FLOWSPEC object to modify the message with an updated UPSTREAM_FLOWSPEC object to modify the
resources requested for the upstream traffic flow. This modification resources requested for the upstream traffic flow. This modification
might require the LSP to be re-routed, and in extreme cases might might require the LSP to be re-routed, and in extreme cases might
result in the LSP being torn down when sufficient resources are not result in the LSP being torn down when sufficient resources are not
available. available.
skipping to change at page 6, line 48 skipping to change at page 6, line 48
object. This includes the definition of class types and their object. This includes the definition of class types and their
formats. The class number of the UPSTREAM_ADSPEC object is TBA by formats. The class number of the UPSTREAM_ADSPEC object is TBA by
IANA (of the form 0bbbbbbb). IANA (of the form 0bbbbbbb).
2.3.1. Procedures 2.3.1. Procedures
The UPSTREAM_ADSPEC object MAY be included in any Resv message that The UPSTREAM_ADSPEC object MAY be included in any Resv message that
corresponds to a Path message containing an UPSTREAM_FLOWSPEC object. corresponds to a Path message containing an UPSTREAM_FLOWSPEC object.
The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the
C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents of C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents of
the UPSTREAM_ADSPEC Object MUST be constructed using a consistent the UPSTREAM_ADSPEC Object MUST be constructed using a format and
format and procedures used to construct the ADSPEC object that will procedures consistent with those used to construct the ADSPEC object
be used for the LSP, e.g., [RFC2210] or [MEF-TRAFFIC]. The that will be used for the LSP, e.g., [RFC2210] or [MEF-TRAFFIC]. The
UPSTREAM_ADSPEC object is processed using the same procedures as the UPSTREAM_ADSPEC object is processed using the same procedures as the
ADSPEC object and as such, MAY be updated or added at transit nodes. ADSPEC object and as such, MAY be updated or added at transit nodes.
3. Packet Formats 3. Packet Formats
This section presents the RSVP message related formats as modified by This section presents the RSVP message related formats as modified by
this section. Unmodified formats are not listed. Three new objects this section. This document modifies formats defined in [RFC2205],
are defined in this section: [RFC3209] and [RFC3473]. See [RSVP-BNF] for the syntax used by RSVP.
Unmodified formats are not listed. Three new objects are defined in
this section:
Object name Applicable RSVP messages Object name Applicable RSVP messages
--------------- ------------------------ --------------- ------------------------
UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify
(via sender descriptor) (via sender descriptor)
UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and
Notify (via flow descriptor list) Notify (via flow descriptor list)
UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and
Notify (via flow descriptor list) Notify (via flow descriptor list)
skipping to change at page 10, line 22 skipping to change at page 10, line 22
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
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.
7.2. Informative References 7.2. Informative References
[GMPLS-PBBTE] Fedyk, D., et al "GMPLS control of Ethernet" , [GMPLS-PBBTE] Fedyk, D., et al "GMPLS control of Ethernet" ,
draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt, Work in draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt, Work in
progress, April 2008. progress, July 2008.
[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic [MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic
Parameters," Parameters,"
draft-ietf-ccamp-ethernet-traffic-parameters-04.txt, draft-ietf-ccamp-ethernet-traffic-parameters-06.txt,
Work in progress, April 2008. Work in progress, October 2008.
[RFC4606] Mannie, E., Papadimitriou, D., "Generalized [RFC4606] Mannie, E., Papadimitriou, D., "Generalized
Multi-Protocol Label Switching (GMPLS) Extensions for Multi-Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006. Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Extensions for G.709 Label Switching (GMPLS) Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, January Optical Transport Networks Control", RFC 4328, January
2006. 2006.
[RSVP-BNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax
Used in Various Protocol Specifications", Work in
progress. draft-farrel-rtg-common-bnf-07.txt, November
2008.
[SEC-FRAMEWORK] Fang, L., Ed., "Security Framework for MPLS and [SEC-FRAMEWORK] Fang, L., Ed., "Security Framework for MPLS and
GMPLS Networks", GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-02.txt, draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt,
Work in progress, February 2008. Work in progress, November 2008.
8. Authors' Addresses 8. Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Attila Takacs Attila Takacs
Ericsson Ericsson
1. Laborc u. 1. Laborc u.
1037 Budapest, Hungary 1037 Budapest, Hungary
Phone: +36-1-4377044 Phone: +36-1-4377044
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Diego Caviglia Diego Caviglia
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
skipping to change at line 618 skipping to change at line 627
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Tue Apr 29 11:46:28 EDT 2008 Generated on: Thu Nov 13 15:24:58 EST 2008
 End of changes. 16 change blocks. 
25 lines changed or deleted 33 lines changed or added

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