draft-varga-pce-generalized-bandwidth.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- vi: set smarttab sw=4 tabstop=4: -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-varga-pce-generalized-bandwidth-00" ipr="trust200902">
	<front>
		<title abbrev="Generalized Bandwidth">
			PCEP Extensions for Generalized Bandwidth
		</title>

		<author fullname="Robert Varga" initials="R." surname="Varga">
			<organization>Pantheon Technologies SRO</organization>
			<address>
				<postal>
					<street>Mlynske Nivy 56</street>
					<city>Bratislava</city>
					<code>821 05</code>
					<country>Slovakia</country>
				</postal>
				<email>robert.varga@pantheon.sk</email>
			</address>
		</author>

		<author fullname="Cyril Margaria" initials="C." surname="Margaria">
			<!-- FIXME: more details once Cyril agrees to participate -->
		</author>

		<date day="10" month="January" year="2013" />

		<workgroup>Network Working Group</workgroup>

		<abstract>
			<t>
				The Path Computation Element (PCE) provides functions of path
				computation in support of traffic engineering (TE) in Multi-Protocol
				Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
			</t>
			<t>
				When a Path Computation Client (PCC) requests a PCE for a route, it
				may request a specific amount of bandwidth for a TE LSP. Protocol
				support for this capability is described in <xref target="RFC5440"/>,
				which defines the BANDWIDTH object for this purpose.
			</t>
			<t>
				Unfortunately the definition provided therein does not allow the
				object to be extended to carry information and semantics necessary
				to cover requirements in GMPLS deployments. This document describes
				a mechanism which can be used by peers participating in a PCEP session
				to agree on using an extensible definition of BANDWIDTH.
			</t>
		</abstract>

		<note title="Requirements Language">
			<t>
				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 <xref target="RFC2119"/>.
			</t>
		</note>
	</front>

	<middle>
		<section title="Introduction">
			<t>
				<xref target="RFC5440"/> describes the Path Computation Element
				Protocol PCEP.  PCEP defines the communication between a Path Computation
				Client (PCC) and a Path Computation Element (PCE), or between PCE and PCE,
				enabling computation of Multiprotocol Label Switching (MPLS) Traffic
				Engineered Label Switched Paths (TE LSPs).
			</t>

			<t>
				<xref target='I-D.ietf-pce-gmpls-pcep-extensions'/> specifies a set of
				extensions to PCEP to enable its use in GMPLS networks. Among GMPLS-specific
				objects, it also defines GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCE,
				as replacements for BANDWIDTH and LOAD-BALANCE objects defined in
				<xref target="RFC5440"/>. The definition is needed because <xref target="RFC5440"/>,
				does not provide any way of extending BANDWIDTH and LOAD-BALANCE objects,
				eventhough it provides extension points in all other objects it defines.
			</t>

			<t>
				<xref target='I-D.ietf-pce-gmpls-pcep-extensions'/> then defines a new
				definition of PCEP message format, which rolls into it all previously
				published PCEP extensions (like <xref target="RFC5521"/> and <xref target="RFC5541"/>).
				This places a requirement for any strictly-GMPLS compliant implementation to
				also understand all those extensions.
			</t>

			<t>
				This document describes an alternative approach, which works by allowing
				peers to negotiate the use of an updated definition of the BANDWIDTH and
				LOAD-BALANCE objects and their on-wire format, which meets the requirements
				set out in <xref target="I-D.ietf-pce-gmpls-aps-req"/>, while also providing
				extension points on-par with other objects defined in <xref target="RFC5440"/>.
			</t>

			<t>
				The motivation for this proposal is to take out the base protocol fixes
				from <xref target='I-D.ietf-pce-gmpls-pcep-extensions'/> and present them
				for use by other protocol extensions, without them needing to pull in all
				the other parts of GMPLS extensions. This will hopefully greatly simplify
				<xref target='I-D.ietf-pce-gmpls-pcep-extensions'/> and ease the job of
				implementing it within existing PCEP stacks.
			</t>
		</section>

		<section title="Terminology">
			<t>
				This document uses the following terms defined in <xref target="RFC5440"/>:
				PCC, PCE, PCEP Peer.
			</t>
			<t>
				This document uses the following terms defined in <xref target="RFC2210"/>:
				SENDER_TSPEC.
			</t>

			<t>
				The following terms are defined in this document:
				<list style="hanging">
					<t hangText="Traffic Specification:">
						A subobject which encapsulates an
						<xref target="RFC2210">RFC2210 SENDER_TSPEC object</xref>.
						Note that "object" here does not refer to a PCEP object,
						and to prevent confusion this text refers to that entity
						just as "SENDER_TSPEC".
					</t>
				</list>
			</t>
		</section>

		<section anchor="Extensions" title="Protocol Procedures and Extensions">
			<section anchor="Negotiation" title="Capability Negotiation">
				<t>
					During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) have to
					negotiate the use of this extension. A PCEP speaker includes the
					"Generalized Bandwidth Capability" TLV, described in
					<xref target="Capability-TLV"/>. The TLV contains a set of flags, which
					indicate the speaker's support for asymmetric bandwidth and which
					Traffic Specification are supported by the advertizing peer.
				</t>

				<t>
					The presence of the Generalized Bandwidth Capability TLV in
					a speaker's OPEN Object indicates that the speaker is willing to
					use the BANDWIDTH object definition specified in this document.
				</t>

				<t>
					The PCEP protocol extensions for generalized bandwidth object MUST NOT
					be used if one or both PCEP speakers have not included the Generalized
					Bandwidth Capability TLV in its OPEN object. If both peers have agreed
					to use these extension, the object formats defined in this document
					MUST be used. If any of these requirements is violated, the receiving
					peer is expected to conform to malformed object processing defined in
					Section 4.2.6 of <xref target="RFC5440"/>.
				</t>
			</section>

			<section anchor="Capability-TLV" title="Generalized Bandwidth Capability TLV">
				<t>
					The format of the GENERALIZED-BANDWIDTH-CAPABILITY TLV is shown in the
					following figure:
				</t>

				<figure anchor="Capability-TLV-Fmt" title="GENERALIZED-BANDWIDTH-CAPABILITY TLV format">
					<artwork>
<![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type=[TBD]         |            Length=4           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|I|S|G|E|                  Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
]]>
					</artwork>
				</figure>

				<t>
					The value comprises a single field - Flags (32 bits).

					<list style="hanging">
						<t hangText="A (ASYMMETRIC-BANDWIDTH-CAPABILITY - 1 bit):">
							If set to 1 by a speaker, the A flag indicates, that the
							speaker supports asymmetric bandwidth specification.
						</t>

						<t hangText="I (INTSERV-BANDWIDTH-CAPABILITY - 1 bit):">
							If set to 1 by a speaker, the I flag indicates, that the
							speaker supports specification of Intserv traffic specification
							as defined by <xref target="RFC2210"/>.
						</t> 

						<t hangText="S (SONET-SDH-BANDWIDTH-CAPABILITY - 1 bit):">
							If set to 1 by a speaker, the S flag indicates, that the
							speaker supports specification of SONET/SDH traffic
							specification as defined by <xref target="RFC4606"/>.
						</t> 

						<t hangText="G (G709-BANDWIDTH-CAPABILITY - 1 bit):">
							If set to 1 by a speaker, the G flag indicates, that the
							speaker supports specification of G.709 traffic specification
							as defined by <xref target="RFC4328"/>.
						</t>

						<t hangText="E (ETHERNET-BANDWIDTH-CAPABILITY - 1 bit):">
							If set to 1 by a speaker, the E flag indicates, that the
							speaker supports specification of Ethernet traffic
							specification as defined by <xref target="RFC6003"/>.
						</t> 
					</list>

					Unassigned bits are considered reserved. They MUST be set to 0 on
					transmission and MUST be ignored on receipt.
				</t>
			</section>

			<section anchor="BANDWIDTH-Object" title="BANDWIDTH Object">
				<t>
					Object header of BANDWIDTH object is kept intact in its
					<xref target="RFC5440"/> definition. The object's length can be
					variable. Object payload format depends on the value of
					ASYMMETRIC-BANDWIDTH-CAPABILITY bit: if the value is 0, then the
					<xref target="UNIDIR-BANDWIDTH-Object">unidirectional format</xref> is
					used, otherwise the
					<xref target="BIDIR-BANDWIDTH-Object">bidirectional format</xref> is
					used.
				</t>

				<section anchor="UNIDIR-BANDWIDTH-Object" title="Unidirectional BANDWIDTH Object">
					<t>
						The Unidirectional format of BANDWIDTH object is as follows:
					</t>

					<figure anchor="BANDWIDTH-UNIDIR-OBJ-Fmt" title="Unidirectional BANDWIDTH Object format">
						<artwork>
<![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                     Traffic Specification                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
						</artwork>
					</figure>

					<t>
						<list style="hanging">
							<t hangText="Traffic Specification:">
								Traffic specification in the forward direction.
							</t>
						</list>
					</t>
				</section>

				<section anchor="BIDIR-BANDWIDTH-Object" title="Bidirectional BANDWIDTH Object">
					<t>
						The Bidirectional format of BANDWIDTH object is as follows:
					</t>

					<figure anchor="BANDWIDTH-BIDIR-OBJ-Fmt" title="Bidirectional BANDWIDTH Object format">
						<artwork>
<![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~               Forward Traffic Specification                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~               Reverse Traffic Specification                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
						</artwork>
					</figure>

					<t>
						<list style="hanging">
							<t hangText="Forward Traffic Specification:">
								Traffic specification along the forward direction of
								the LSP.
							</t>

							<t hangText="Reverse Traffic Specification:">
								Traffic specification along the reverse direction of
								the LSP.
							</t>
						</list>
					</t>
				</section>

			</section>

			<section anchor="TRAFFIC-SPEC" title="Traffic Specification field">
				<t>
					The format of Traffic Specification field is as follows:

					<figure anchor="TRAFFIC-SPEC-Fmt" title="Traffic Specification format">
						<artwork>
<![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Traffic Specification Length |   SENDER_TSPEC Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  TSpec Type   |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       SENDER_TSPEC                            ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                      Optional TLVs                          // 
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
						</artwork>
					</figure>

					<list style="hanging">
						<t hangText="Traffic Specification Length:">
							Length of the entire Traffic Specification field.
						</t>
						<t hangText="SENDER_TSPEC Length:">
							Length of SENDER_TSPEC field.
						</t>
						<t hangText="TSpec Type:">
							Type of SENDER_TSPEC field. Value of 0 indicates a
							<xref target="RFC5440"/>-style specification.
						</t>
						<t hangText="Reserved:">
							Reserved for future use. MUST be zero on transmit
							and ignored on reception.
						</t>
						<t hangText="SENDER_TSPEC">
							Body of SENDER_TSPEC, formatted according to the
							defining document.

							FIXME: backward-compatible IEEE32 bandwidth for
							RFC5440 compatibility (type=0).
						</t>
					</list>

					See capability bit descriptions in <xref target="Capability-TLV"/>
					for external references to documents defining specific values of
					TSpec Type and formats of SENDER_TSPEC.

					Optional TLVs may be included within the BANDWIDTH object body
					to extend the information conveyed by the object. The specification
					of such TLVs is outside the scope of this document.
				</t>
			</section>
		</section>

		<section anchor="IANA-considerations" title="IANA considerations">
			<section anchor="PCEP-BANDWIDTH-Object" title="PCEP-BANDWIDTH Object">
				<t>This document defines a new format and semantics of PCEP-BANDWIDTH
					Object. These are a strict superset of original semantics.
				</t>
			</section>

			<section anchor="PCEP-TLV-Type-Indicators" title="PCEP TLV Type Indicators">
				<t>This document defines the following new PCEP TLVs:</t>

				<texttable anchor="PCEP-New-TLV-CP" style="none" suppress-title="true">
					<ttcol align="center" width='20%'>Value</ttcol>
					<ttcol align="left" width='40%'>Meaning </ttcol>
					<ttcol align="left" width='40%'>Reference </ttcol>
					<c>TBD</c><c>&nbsp;GENERALIZED-BANDWIDTH-CAPABILITY</c><c>This document</c>
				</texttable>
			</section>
		</section> 

		<section anchor="Security" title="Security Considerations">
			<t>
				The security considerations described in <xref target="RFC5440"></xref> 
				apply to the extensions described in this document. These extensions do
				not have any impact on security and threat models defined therein.
			</t>
		</section>

		<section anchor="Acknowledgements" title="Acknowledgements">
			<t>
				The author would like to thank Dana Kutenicsova, Ina Minei and Jan Medved
				for their contributions to this document and to the authors of 
				<xref target='I-D.ietf-pce-gmpls-pcep-extensions'/> for original TSpec
				encapsulation approach, which is reused in this document.
			</t>
		</section>

	</middle>

	<back>
		<references title="Normative References">
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2210.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4328.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4606.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5521.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5541.xml"?>
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6003.xml"?>
			<?rfc include="reference.I-D.ietf-pce-gmpls-aps-req"?>
			<?rfc include="reference.I-D.ietf-pce-gmpls-pcep-extensions"?>
		</references>

		<references title="Informative References">
			<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5557.xml"?>
		</references>
	</back>
</rfc>