One document matched: draft-ietf-pcn-3-in-1-encoding-04.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY draft-ietf-tsvwg-ecn-tunnel SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-tunnel.xml">
<!ENTITY draft-ietf-pcn-cl-edge-behaviour SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-cl-edge-behaviour.xml">
<!ENTITY draft-ietf-pcn-sm-edge-behaviour SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-sm-edge-behaviour.xml">
<!ENTITY draft-ietf-pcn-encoding-comparison SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcn-encoding-comparison.xml">
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2474 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC3168 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC4301 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC5670 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5696 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC5559 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5559.xml">
<!ENTITY RFC5129 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5129.xml">
]>
<rfc category="exp" docName="draft-ietf-pcn-3-in-1-encoding-04"
ipr="trust200902">
<front>
<title abbrev="3-in-1 PCN Encoding">Encoding 3 PCN-States in the IP header using a single DSCP</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<author fullname="Toby Moncaster" initials="T." surname="Moncaster">
<organization>Moncaster Internet Consulting</organization>
<address>
<postal>
<street>Dukes</street>
<street>Layer Marney</street>
<city>Colchester</city>
<code>CO5 9UZ</code>
<country>UK</country>
</postal>
<phone>+44 7764 185416</phone>
<email>toby@moncaster.com</email>
<uri>http://www.moncaster.com/</uri>
</address>
</author>
<author initials="M." surname="Menth" fullname="Michael Menth">
<organization>University of Tuebingen</organization>
<address>
<postal>
<street>Sand 13</street>
<code>72076</code><city>Tuebingen</city>
<country>Germany</country>
</postal>
<phone>+49 7071 2970505</phone>
<email>menth@informatik.uni-tuebingen.de</email>
</address>
</author>
<date day="11" month="January" year="2011" />
<area>Transport</area>
<workgroup>Congestion and Pre-Congestion Notification</workgroup>
<keyword>Quality of Service</keyword>
<keyword>QoS</keyword>
<keyword>Congestion Control</keyword>
<keyword>Congestion Notification</keyword>
<keyword>Tunnelling</keyword>
<keyword>Encapsulation & Decapsulation</keyword>
<keyword>Differentiated Services</keyword>
<keyword>Integrated Services</keyword>
<keyword>Signalling</keyword>
<keyword>Protocol</keyword>
<keyword>Flow Admission Control</keyword>
<keyword>Flow Termination</keyword>
<abstract>
<t>
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
On every link in the PCN domain, the overall rate of the PCN-traffic is
metered, and PCN-packets are appropriately marked when certain
configured rates are exceeded. Egress nodes provide decision points with
information about the PCN-marks of PCN-packets which allows them to take
decisions about whether to admit or block a new flow request, and to
terminate some already admitted flows during serious pre-congestion.
</t>
<t>
This document specifies how PCN-marks are to be encoded into the IP header
by re-using the Explicit Congestion Notification (ECN) codepoints within a
PCN-domain. This encoding builds on the baseline encoding of RFC5696 and
provides for three different PCN marking states using a single DSCP:
not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM).
Hence, it is called the 3-in-1 PCN encoding.
</t>
</abstract>
</front>
<middle>
<section anchor="pcn3in1_Introduction" title="Introduction">
<t>
The objective of Pre-Congestion Notification (PCN) <xref target="RFC5559"/>
is to protect the quality of service (QoS) of inelastic flows within a
Diffserv domain, in a simple, scalable, and robust fashion. Two mechanisms
are used: admission control, to decide whether to admit or block a new flow
request, and flow termination to terminate some existing
flows during serious pre-congestion. To achieve this, the overall
rate of PCN-traffic is metered on every link in the domain, and PCN-packets
are appropriately marked when certain configured rates are exceeded. These
configured rates are below the rate of the link thus providing notification
to boundary nodes about overloads before any real congestion occurs (hence
"pre-congestion notification").
</t>
<t>
<xref target="RFC5670"/> provides for two metering and marking functions
that are configured with reference rates. Threshold-marking marks all PCN
packets once their traffic rate on a link exceeds the configured reference
rate (PCN-threshold-rate). Excess-traffic-marking marks only those PCN
packets that exceed the configured reference rate (PCN-excess-rate). The
PCN-excess-rate is typically larger than the PCN-threshold-rate
<xref target="RFC5559"/>. Egress nodes monitor the PCN-marks of received
PCN-packets and provide information about the PCN-marks to decision points
which take decisions about flow admission and termination on this basis
<xref target="I-D.ietf-pcn-cl-edge-behaviour"/>,
<xref target="I-D.ietf-pcn-sm-edge-behaviour"/>.
</t>
<t>
The baseline encoding defined in <xref target="RFC5696"/> describes how two
PCN marking states (Not-marked and PCN-Marked) can be encoded using a single Diffserv codepoint. It also
provides an experimental codepoint (EXP), along with guidelines for use of that codepoint.
To support the application of two different marking algorithms in a
PCN-domain, for example as required in
<xref target="I-D.ietf-pcn-cl-edge-behaviour"/>, three PCN marking states are
needed. This document describes an extension to the baseline encoding that
uses the EXP codepoint to provide a third PCN marking state in the IP header, still using a single
Diffserv codepoint. This encoding scheme is called "3-in-1 PCN encoding".
</t>
<t>
This document only concerns the PCN wire protocol encoding for all IP
headers, whether IPv4 or IPv6. It makes no changes or recommendations
concerning algorithms for congestion marking or congestion response. Other
documents define the PCN wire protocol for other header types. For example,
the MPLS encoding is defined in <xref target="RFC5129"/>. Appendix A provides
an informative example for a mapping between the encodings in IP and in MPLS.
</t>
<section anchor="pcn3in1_Changes"
title="Changes in This Version (to be removed by RFC Editor)">
<t>
<list style="hanging">
<t hangText="From draft-ietf-pcn-3-in-1-encoding-03 to -04:">
<list style="symbols">
<t>Updated document to reflect RFC6040.</t>
<t>Re-wrote introduction.</t>
<t>Re-wrote section on applicability.</t>
<t>Re-wrote section on choosing encoding scheme.</t>
<t>Updated author details.</t>
</list>
</t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-02 to -03:">
<list style="symbols">
<t>Corrected mistakes in introduction and improved overall readability.</t>
<t>Added new terminology.</t>
<t>Rewrote a good part of Section 4 and 5 to achieve more clarity.</t>
<t>Added appendix explaining when to use which encoding scheme and how to
encode them in MPLS shim headers.</t>
<t>Added new co-author.</t>
</list>
</t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-01 to -02:"><list
style="symbols">
<t>Corrected mistake in introduction, which wrongly stated
that the threshold-traffic rate is higher than the
excess-traffic rate. Other minor corrections.</t>
<t>Updated acks & refs.</t>
</list></t>
<t hangText="From draft-ietf-pcn-3-in-1-encoding-00 to -01:"><list
style="symbols">
<t>Altered the wording to make sense if draft-ietf-tsvwg-ecn-tunnel
moves to proposed standard.</t>
<t>References updated</t>
</list></t>
<t
hangText="From draft-briscoe-pcn-3-in-1-encoding-00 to draft-ietf-pcn-3-in-1-encoding-00:"><list
style="symbols">
<t>Filename changed to draft-ietf-pcn-3-in-1-encoding.</t>
<t>Introduction altered to include new template description of
PCN.</t>
<t>References updated.</t>
<t>Terminology brought into line with <xref
target="RFC5670"></xref>.</t>
<t>Minor corrections.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="pcn3in1_Reqs_Lang" 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>
<section anchor="pcn3in1_Terminology" title="Terminology">
<t>
General PCN-related terminology is defined in the PCN architecture
<xref target="RFC5559"/>, and terminology specific to packet encoding is defined in
the PCN baseline encoding [RFC5696]. Additional terminology is defined below.
</t>
<t>
<list style="hanging">
<t hangText="PCN encoding:">
mapping of PCN marking states to specific codepoints in the packet header.
</t>
</list>
</t>
</section>
</section>
<section anchor="pcn3in1_Requirement_head"
title="Requirements for and Applicability of 3-in-1 PCN Encoding">
<section anchor="pcn3in1_Requirement"
title="PCN Requirements">
<t>
In accordance with the PCN architecture <xref target="RFC5559"/>,
PCN-ingress-nodes control packets entering a PCN-domain. Packets
belonging to PCN-controlled flows are subject to PCN-metering and
-marking, and PCN-ingress-nodes mark
them as Not-marked (PCN-colouring). Any node in the PCN-domain may
perform PCN-metering and -marking and mark PCN-packets if needed.
There are two different metering and marking schemes: threshold-marking
and excess-traffic-marking <xref target="RFC5670"/>. Some edge
behaviors require only a single marking scheme
<xref target="I-D.ietf-pcn-sm-edge-behaviour"/>, others require both
<xref target="I-D.ietf-pcn-cl-edge-behaviour"/>. In the latter case,
three PCN marking states are needed: not-marked (NM) to indicate
not-marked packets, threshold-marked (ThM) to indicate packets marked
by the threshold-marker, and excess-traffic-marked (ETM) to indicate
packets marked by the excess-traffic-marker <xref target="RFC5670"/>.
Threshold-marking and excess-traffic-marking are configured to start marking packets
at different load conditions, so one marking scheme indicates more severe
pre-congestion than the other. Therefore, a fourth PCN
marking state indicating that a packet is marked by both markers is
not needed. However a fourth codepoint is required to indicate packets
that are not PCN-capable (the not-PCN codepoint).
</t>
<t>
In all current PCN edge behaviors that use two marking schemes
<xref target="RFC5559"/>, <xref target="I-D.ietf-pcn-cl-edge-behaviour"/>,
excess-traffic-marking is configured with a larger reference rate than
threshold-marking. We take this as a rule and define excess-traffic-marked
as a more severe PCN-mark than threshold-marked.
</t>
</section>
<section anchor="pcn3in1_Requirements_Baseline_Encoding"
title="Requirements Imposed by Baseline Encoding">
<t>
The baseline encoding scheme <xref target="RFC5696"/> was defined so that
it could be extended to accommodate an additional marking state. It provides
rules to embed the encoding of two PCN states in the IP header.
<xref target="pcn3in1_Fig_DS_IP"/> shows the structure of the former type-of-service field.
It contains the 6-bit
Differentiated Services (DS) field that holds the DS codepoint
(DSCP) <xref target="RFC2474"/> and the 2-bit ECN field <xref target="RFC3168"/>.
</t>
<figure anchor="pcn3in1_Fig_DS_IP" title="Structure of the former type-of-service field in IP">
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
<t>
Baseline encoding defines that the DSCP must be set to a PCN-compatible DSCP n
and the ECN-field <xref target="RFC3168"/> indicates the specific PCN-mark.
Baseline encoding offers four possible encoding states within a single DSCP
with the following restrictions.
<list style="symbols">
<t>Codepoint `00´ (not-ECT) is used to indicate non-PCN traffic as "not-PCN".
This allows both PCN and non-PCN traffic to use the same DSCP.</t>
<t>Codepoint `10´ (ECT(0)) is used to indicate Not-marked PCN traffic.</t>
<t>Codepoint `11´ (CE) is used to indicate the most severe PCN-mark.</t>
<t>Codepoint `01´ (ECT(1)) is available for experimental use and may be re-used
by other PCN encodings such as the presently defined 3-in-1 PCN encoding (subject
to the rules defined in <xref target="RFC5696"></xref>).</t>
</list>
</t>
<t><xref target="RFC6040"></xref> defines rules for the encapsulation and decapsulation
of ECN markings within IP-in-IP tunnels. This RFC removes some of the constraints that
existed when <xref target="RFC5696"></xref> was written. Happily the rules for use of the
EXP codepoint are fully compatible with <xref target="RFC6040"></xref>. In particular,
the relative severity of each marking is the same: CE (PM) is more severe than ECT(1) (EXP) is more
severe than ECT(0) (NM). This is discussed in more detail in both the baseline encoding document
<xref target="RFC5696"/> and in <xref target="I-D.ietf-pcn-encoding-comparison"/>.
</t>
</section>
<section anchor="pcn3in1_Requirements_Applicability"
title="Applicability of 3-in-1 PCN Encoding">
<t>
The 3-in-1 encoding is applicable in situations where two marking schemes are being used in the PCN-domain.
In some circumstances it can also be used in PCN-domains with only a single marking scheme in use. Further guidance
on choosing an encoding scheme can be found in <xref target="pcn3in1_Recommendation_PCN_Encoding_Schemes"/>.
All nodes within the PCN-domain MUST be fully compliant with the
ECN encapsulation rules set out in <xref target="RFC6040"/>. As such the encoding
is not applicable in situations where legacy tunnels might exist.
</t>
</section>
</section>
<section anchor="pcn3in1_Encoding" title="Definition of 3-in-1 PCN Encoding">
<t>
The 3-in-1 PCN encoding scheme is an extension of the baseline encoding scheme
defined in <xref target="RFC5696"/>. The PCN requirements and the extension
rules for baseline encoding presented in the previous section determine how PCN
encoding states are carried in the IP headers. This is shown in
<xref target="pcn3in1_Fig_Encoding"/>.
</t>
<figure anchor="pcn3in1_Fig_Encoding" title="3-in-1 PCN Encoding">
<artwork><![CDATA[
+--------+----------------------------------------------------+
| | Codepoint in ECN field of IP header |
| DSCP | <RFC3168 codepoint name> |
| +--------------+-------------+-------------+---------+
| | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
]]></artwork>
</figure>
<t>
Like baseline encoding, 3-in-1 PCN encoding also uses a PCN compatible DSCP n
and the ECN field for the encoding of PCN-marks. The PCN-marks have the following
meaning.
<list style="hanging">
<t hangText="Not-PCN:">indicates a non-PCN-packet, i.e., a packet that is not
subject to PCN metering and marking.</t>
<t hangText="NM:">Not-marked. Indicates a PCN-packet that has not yet been
marked by any PCN marker.</t>
<t hangText="ThM:">Threshold-marked. Indicates a PCN-packet that has been
marked by a threshold-marker <xref target="RFC5670"/>.</t>
<t hangText="ETM:">Excess-traffic-marked. Indicates a PCN-packet that has been
marked by an excess-traffic-marker <xref target="RFC5670"/>.</t>
</list>
</t>
</section>
<section anchor="pcn3in1_Compliant_Node_Behaviour"
title="Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding">
<t>
To be compliant with the 3-in-1 PCN Encoding, an PCN interior node
behaves as follows:
<list style="symbols">
<t>It MUST change NM to ThM if the threshold-meter function
indicates a need to mark the packet;</t>
<t>It MUST change NM or ThM to ETM if the excess-traffic-meter
function indicates a need to mark the packet;</t>
<t>It MUST NOT change not-PCN to NM, ThM, or ETM;</t>
<t>It MUST NOT change a NM, ThM, or ETM to not-PCN;</t>
<t>It MUST NOT change ThM to NM;</t>
<t>It MUST NOT change ETM to ThM or to NM;</t>
</list>
</t>
<t>
In other words, a PCN interior node MUST NOT mark PCN-packets into non-PCN
packets and vice-versa, and it may increase the severity of the PCN-mark of
a PCN-packet, but it MUST NOT decrease it.
</t>
</section>
<section anchor="pcn3in1_Backward_Compatibility"
title="Backward Compatibility">
<t>
Discussion of backward compatibility between PCN encoding schemes and previous
uses of the ECN field is given in Section 6 of <xref target="RFC5696"/>.
</t>
<section anchor="pcn3in1_Backward_Compatibility_pre-PCN"
title="Backward Compatibility with Pre-existing PCN Implementations">
<t>
This encoding complies with the rules for extending the baseline PCN encoding
schemes in Section 5 of <xref target="RFC5696"/>.
</t>
<t>
The term "compatibility" is meant in the following sense. It is
possible to operate nodes with baseline encoding <xref target="RFC5696"/> and 3-in-1
encoding in the same PCN domain. The nodes with baseline encoding
MUST perform excess-traffic-marking because the 11 codepoint of
3-in-1 encoding also means excess-traffic-marked.
PCN-boundary-nodes of such domains are required to interpret the
full 3-in-1 encoding and not just baseline encoding, otherwise
they cannot interpret the 01 codepoint.
</t>
<t>
Using nodes that perform only excess-traffic-marking may make
sense in networks using the CL edge behavior
<xref target="I-D.ietf-pcn-cl-edge-behaviour"/>. Such nodes are able to notify
the egress only about severe pre-congestion when traffic needs to
be terminated. This seems reasonable for locations that are not
expected to see any pre-congestion, but excess-traffic-marking
gives them a means to terminate traffic if unexpected overload
occurs.
</t>
</section>
<section anchor="pcn3in1_Recommendation_PCN_Encoding_Schemes"
title="Recommendations for the Use of PCN Encoding Schemes">
<t>NOTE: This sub-section is informative not normative.</t>
<t>
When deciding which PCN encoding is suitable an operator needs to take account
of how many PCN states need to be encoded. The following table gives guidelines
on which encoding to use with either threshold-marking, excess-traffic marking or both.</t>
<figure anchor="pcn3in1_Fig_Encoding_Schemes" title="Guidelines for choosing PCN encoding schemes">
<artwork><![CDATA[
+------------------------+--------------------------------+
| Used marking schemes | Recommended encoding scheme |
+------------------------+--------------------------------+
| Only threshold-marking | Baseline encoding [RFC5696] |
+------------------------+--------------------------------+
| Only excess-traffic- | Baseline encoding [RFC5696] |
| marking | or 3-in-1 PCN encoding |
+------------------------+--------------------------------+
| Threshold-marking and | 3-in-1 PCN encoding |
| excess-traffic-marking | |
+------------------------+--------------------------------+
]]></artwork>
</figure>
<section anchor="pcn3in1_Recommendation_PCN_Encoding_Schemes_ETM_TM"
title="Use of Both Excess-Traffic-Marking and Threshold-Marking">
<t>
If both excess-traffic-marking and threshold-marking are enabled in a
PCN-domain, 3-in-1 encoding should be used as described in this document.
</t>
</section>
<section anchor="pcn3in1_Recommendation_PCN_Encoding_Schemes_ETM"
title="Unique Use of Excess-Traffic-Marking">
<t>
If only excess-traffic-marking is enabled in a PCN-domain, baseline
encoding or 3-in-1 encoding may be used. They lead to the same encoding
because PCN-boundary nodes will interpret baseline "PCN-marked (PM)"
as "excess-traffic-marked (ETM)".
</t>
</section>
<section anchor="pcn3in1_Recommendation_PCN_Encoding_Schemes_TM"
title="Unique Use of Threshold-Marking">
<t>
No scheme is currently proposed that solely uses threshold-marking. If such
a scheme is proposed, the choice of encoding scheme will depend on whether
nodes are compliant with <xref target="RFC6040"/> or not. Where it is certain
that all nodes in the PCN-domain are compliant then either 3-in-1 encoding
or baseline encoding are suitable. If legacy tunnel decapsulators exist
within the PCN-domain then baseline encoding SHOULD be used.
</t>
</section>
</section>
</section>
<section anchor="pcn3in1_IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="pcn3in1_Sec_Consider" title="Security Considerations">
<t>
The security concerns relating to this extended PCN encoding are the same
as those in <xref target="RFC5696"/>. In summary, PCN-boundary nodes are
responsible for ensuring inappropriate PCN markings do not leak into or
out of a PCN domain, and the current phase of the PCN architecture assumes
that all the nodes of a PCN-domain are entirely under the control of a
single operator, or a set of operators who trust each other.
</t>
<t>
Given the only difference between the baseline encoding and the present
3-in-1 encoding is the use of the 01 codepoint, no new security issues are
raised, as this codepoint was already available for experimental use in
the baseline encoding.
</t>
</section>
<section anchor="pcn3in1_Conclusions" title="Conclusions">
<t>
The 3-in-1 PCN encoding uses a PCN-compatible DSCP and the ECN field to
encode PCN-marks. One codepoint allows non-PCN traffic to be carried with
the same PCN-compatible DSCP and three other codepoints support three PCN
marking states with different levels of severity. The use of this PCN
encoding scheme presupposes that any tunnels in the PCN region have been
updated to comply with <xref target="RFC6040"/>.
</t>
</section>
<section anchor="pcn3in1_Acknowledgements" title="Acknowledgements">
<t>
Thanks to Phil Eardley, Teco Boot, and Kwok Ho Chan for reviewing this document.
</t>
</section>
<section anchor="pcn3in1_Comments_Solicited" title="Comments Solicited">
<t>To be removed by RFC Editor: Comments and questions are encouraged
and very welcome. They can be addressed to the IETF Congestion and
Pre-Congestion working group mailing list <pcn@ietf.org>, and/or
to the authors.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.5129" ?>
<?rfc include="reference.RFC.5559" ?>
<?rfc include="reference.RFC.5670" ?>
<?rfc include="reference.RFC.5696" ?>
<?rfc include="reference.RFC.6040" ?>
</references>
<references title="Informative References">
&draft-ietf-pcn-cl-edge-behaviour;
&draft-ietf-pcn-sm-edge-behaviour;
&draft-ietf-pcn-encoding-comparison;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:25:57 |