RFC 5696
Baseline Encoding and Transport of Pre-Congestion Information
RFC 5696 🎀 Baseline Encoding and Transport of Pre-Congestion Information
okay bestie, let's get into it 💅 RFC 5696 is a Standards Track doc, dated November 2009, written by T. Moncaster (BT), B. Briscoe (BT), and M. Menth (University of Wuerzburg) 🦋 It doesn't list anything it obsoletes or updates in its header, so it's standing on its own ✨
Abstract 🌸
okay so the whole goal of Pre-Congestion Notification (PCN) is to keep the quality of service (QoS) of inelastic flows safe inside a Diffserv domain 🛡️ the way it does that is by marking PCN-packets once the traffic rate on a link goes past certain configured thresholds. then the marks can be checked to see how close the domain is to congestion. this doc explains how those marks get encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints inside these domains 🧚 the baseline version only has two PCN encoding states, Not-marked and PCN-marked. more than one level of marking severity might need future extensions 👑
Status of This Memo 🍓
this doc is an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 💬 if you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 and distribution is unlimited, so share away 🌈
Copyright Notice 💜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ✨
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, because they spell out your rights and restrictions 🙈 any Code Components pulled out of this doc have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the BSD License 🫶
some of this doc may come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 so unless you get a proper license from them, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. List of Abbreviations . . . . . . . . . . . . . . . . . . 4
4. Encoding Two PCN States in IP . . . . . . . . . . . . . . . . 4
4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 5
4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 6
4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 7
4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 7
4.4.1. Co-Existence of PCN and Not-PCN Traffic . . . . . . . 8
5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. PCN Deployment Considerations (Informative) . . . . . 11
A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 11
A.2. Rationale for Using ECT(0) for Not-Marked . . . . . . . . 12
Appendix B. Co-Existence of PCN and ECN (Informative) . . . . . . 131. Introduction 🦋
okay so the PCN architecture [RFC5559] is all about protecting the quality of service (QoS) of inelastic flows inside a Diffserv domain, and it does this in a simple, scalable, and robust way 💖 the overall rate of PCN-traffic gets metered on every link in the PCN-domain. when certain configured rates are exceeded, PCN-packets get marked. those configured rates sit below the link's actual rate, so you get a heads-up before any congestion happens. that's where the name "Pre-Congestion Notification" comes from 🫶 the level of marking lets boundary nodes decide whether to admit or block a new flow request. in abnormal circumstances, they can also decide to terminate some existing flows, so the QoS of flows that were already admitted stays protected ✨
this doc specifies how these PCN-marks get encoded into the IP header by reusing bits of the ECN field [RFC3168] 🌈 it also explains how packets get identified as belonging to a PCN-flow. some deployment models need two PCN encoding states, and others need more. the baseline encoding here only gives you two, but it's easy to extend to more states, and the rules for doing that are in Section 5 🧚
2. Requirements Notation 🍓
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 [RFC2119] 📚
3. Terminology and Abbreviations 💅
3.1. Terminology 💜
the terms PCN-capable, PCN-domain, PCN-node, PCN-interior-node, PCN-ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-packets and PCN-marking are used as defined in [RFC5559]. the following extra terms are defined in this doc:
- PCN-compatible Diffserv codepoint - a Diffserv codepoint indicating packets for which the ECN field is used to carry PCN-markings rather than [RFC3168] markings. 🌸
- PCN-marked codepoint - a codepoint that indicates packets that have been marked at a PCN-interior-node using some PCN-marking behaviour [RFC5670]. Abbreviated to PM. 🔥
- Not-marked codepoint - a codepoint that indicates packets that are PCN-capable but that are not PCN-marked. Abbreviated to NM. 🦋
- not-PCN codepoint - a codepoint that indicates packets that are not PCN-capable. 🙈
3.2. List of Abbreviations 🌈
the following abbreviations get used in this doc:
- AF = Assured Forwarding [RFC2597] ✨
- CE = Congestion Experienced [RFC3168] 💥
- CS = Class Selector [RFC2474] 🎀
- DSCP = Diffserv codepoint 🍓
- ECN = Explicit Congestion Notification [RFC3168] 🌸
- ECT = ECN Capable Transport [RFC3168] 🧚
- EF = Expedited Forwarding [RFC3246] 💖
- EXP = Experimental 🧪
- NM = Not-marked 🫶
- PCN = Pre-Congestion Notification 👑
- PM = PCN-marked 💜
4. Encoding Two PCN States in IP 🎀
okay this part is the main event 💅 the PCN encoding states are defined by combining the DSCP and ECN fields in the IP header. the baseline PCN encoding follows the semantics of ECN [RFC3168] super closely ✨ it lets you encode two PCN states, Not-marked and PCN-marked. it also lets traffic that isn't PCN-capable be marked as such (not-PCN) 🙈 codepoints in the IP header are scarce, so the baseline encoding leaves one codepoint free for experimental use 🧪 here's how the states get encoded in IP:
+---------------+-------------+-------------+-------------+---------+
| ECN codepoint | Not-ECT | ECT(0) (10) | ECT(1) (01) | CE (11) |
| | (00) | | | |
+---------------+-------------+-------------+-------------+---------+
| DSCP n | not-PCN | NM | EXP | PM |
+---------------+-------------+-------------+-------------+---------+
Table 1: Encoding PCN in IPin the table, DSCP n is a PCN-compatible Diffserv codepoint (see Section 4.4), and EXP means available for Experimental use. N.B. we're deliberately keeping this codepoint for experimental use only, not local use, so we don't end up with future compatibility issues 🫣
these rules apply to all PCN-traffic 💖
- PCN-traffic MUST be marked with a PCN-compatible Diffserv codepoint. to save DSCPs, Diffserv codepoints SHOULD be chosen that are already defined for use with admission-controlled traffic. Appendix A.1 gives implementors guidance on suitable DSCPs 🧚 guidelines for mixing traffic types within a PCN-domain are in [RFC5670] 📚
- Any packet arriving at the PCN-ingress-node that shares a PCN-compatible DSCP and is not a PCN-packet MUST be marked as not-PCN within the PCN-domain 🙅♀️
- If a packet arrives at the PCN-ingress-node with its ECN field already set to a value other than not-ECT, then appropriate action MUST be taken to meet the requirements of [RFC3168]. the simplest appropriate action is to just drop those packets 💀 but that's a drastic move that an operator may feel is undesirable. Appendix B has more info and sums up other alternative actions that might be taken 🌷
4.1. Marking Packets 🔥
[RFC5670] says that any encoding scheme document must specify the required action to take if one of the marking algorithms indicates that a packet needs to be marked. for the baseline encoding scheme, the required action is simply this:
- If a marking algorithm indicates the need to mark a PCN-packet, then that packet MUST have its PCN codepoint set to 11, PCN-marked. 🌈⭐
4.2. Valid and Invalid Codepoint Transitions ✨
okay bestie, first things first 💅 A PCN-ingress-node MUST set the Not-marked (10) codepoint on any arriving packet that belongs to a PCN-flow. 🎀 It MUST set the not-PCN (00) codepoint on all other packets sharing a PCN-compatible Diffserv codepoint 💖
The only valid codepoint transitions inside a PCN-interior-node are from NM to PM (which should occur if either meter indicates a need to PCN-mark a packet [RFC5670]) and from EXP to PM 🦋 PCN-nodes that only implement the baseline encoding MUST be able to PCN-mark packets that arrive with the EXP codepoint. This should ease the design of experimental schemes that want partial deployment of experimental nodes alongside nodes that only implement the baseline encoding 🫶 Here's the full set of valid and invalid codepoint transitions, all laid out for you:
+-------------------------------------------------+
| Codepoint Out |
+--------------+-------------+-----------+-----------+-----------+
| Codepoint in | not-PCN(00) | NM(10) | EXP(01) | PM(11) |
+--------------+-------------+-----------+-----------+-----------+
| not-PCN(00) | Valid | Not valid | Not valid | Not valid |
+--------------+-------------+-----------+-----------+-----------+
| NM(10) | Not valid | Valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| EXP(01)* | Not valid | Not valid | Valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
| PM(11) | Not valid | Not valid | Not valid | Valid |
+--------------+-------------+-----------+-----------+-----------+
* This MAY cause an alarm to be raised at a management layer.
See paragraph above for an explanation of this transition.
Table 2: Valid and Invalid Codepoint Transitions for
PCN-Packets at PCN-Interior-NodesThe codepoint transition constraints here only apply to the baseline encoding scheme 🌸 Constraints on codepoint transitions for future experimental schemes are discussed in Section 5.
A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all packets it forwards out of the PCN-domain 💜 The only exception is when the PCN-egress-node is certain that revealing other codepoints outside the PCN-domain won't break the guidance in [RFC4774]. For instance, if the PCN-ingress-node has explicitly told the PCN-egress-node that this flow is ECN-capable, then it might be safe to expose other codepoints 👀
4.3. Rationale for Encoding 🧚
The exact encoding was picked because of the constraints set by existing IETF RFCs, especially [RFC3168], [RFC4301], and [RFC4774] 🌈 One of the tightest constraints was that any PCN encoding had to survive being tunnelled through either an IP-in-IP tunnel or an IPsec Tunnel. [ECN-TUN] explains this in more detail. The main effect is that any PCN-marking has to carry the 11 codepoint in the ECN field, because that's the only codepoint guaranteed to be copied down into the forwarded header upon decapsulation 😭 Another constraint was the need to minimise the use of Diffserv codepoints, since there's a limited supply of Standards Track codepoints left. Section 4.4 explains how we squeezed this down even further by reusing pre-existing Diffserv codepoint(s), so non-PCN traffic can still be told apart from PCN traffic 🔥
There were a bunch of factors considered before setting 10 as the NM state instead of 01. These included similarity to ECN, the presence of tunnels within the domain, leakage into and out of the PCN-domain, and incremental deployment (see Appendix A.2) 🍓
The encoding scheme above seems to meet all these constraints and ends up looking very similar to ECN. Honestly not surprising, given how similar PCN and ECN are in architectural intent 💅
4.4. PCN-Compatible Diffserv Codepoints 🎀
Equipment complying with the baseline PCN encoding MUST allow PCN to be enabled for certain Diffserv codepoints. This document defines the term "PCN-compatible Diffserv codepoint" for such a DSCP. To be clear, packets with such a DSCP are only PCN-enabled if they're within a PCN-domain and have their ECN field set to a codepoint other than not-PCN ✨
Enabling PCN-marking behaviour for a specific DSCP turns off any other marking behaviour (for example, enabling PCN replaces the default ECN marking behaviour introduced in [RFC3168]) with the PCN-metering and -marking behaviours described in [RFC5670]). This keeps things compliant with the Best Current Practice (BCP) guidance set out in [RFC4774] 🙈
The PCN working group chose not to define a single DSCP for PCN, and there were three big reasons. First, the PCN mechanism applies to a variety of different traffic classes. Second, Standards Track DSCPs are running out fast. Third, PCN isn't a scheduling behaviour. It's really more of a marking behaviour, kind of like ECN but meant for inelastic traffic. More details are in the informational Appendix A.1 🦋
4.4.1. Co-Existence of PCN and Not-PCN Traffic 🌸
Pool 1 DSCPs are scarce, and PCN is meant to be a marking behaviour that could be applied to a bunch of different DSCPs. So it's essential that we provide a not-PCN state 😤 As stated above (and expanded in Appendix A.1), the aim is for PCN to re-use existing DSCPs. Because PCN redefines what the ECN field means for those DSCPs, it's important to let an operator still use the DSCP for non-PCN traffic. That's exactly what the not-PCN state in the encoding scheme is for. Section 3.5 of [RFC5559] discusses how competing non-PCN traffic should be handled 💖
5. Rules for Experimental Encoding Schemes 🧪
Any experimental encoding scheme MUST follow these rules so it stays backward compatible with this baseline scheme:
- All PCN-interior-nodes within a PCN-domain MUST interpret the 00 codepoint in the ECN field as not-PCN, and MUST NOT change it to another value. So a PCN-ingress-node that wants to turn off PCN-marking for a packet with a PCN-compatible Diffserv codepoint MUST set the ECN field to 00 💅
- The 11 codepoint in the ECN field MUST indicate that the packet has been PCN-marked because one or both of the meters indicated a need to PCN-mark a packet [RFC5670]. The experimental scheme MUST define which meter(s) trigger this marking 🔥
- The 01 Experimental codepoint in the ECN field MAY mean PCN-marked, or it MAY carry some other meaning. However, any experimental scheme MUST define its meaning in the context of that experiment 🌈
- If both the 01 and 11 codepoints are being used to indicate PCN-marked, then the 11 codepoint MUST be taken to be the more severe marking, and the choice of which meter sets which mark MUST be defined 👑
- Once set, the 11 codepoint in the ECN field MUST NOT be changed to any other codepoint 🛑
- Any experimental scheme MUST include details of all valid and invalid codepoint transitions at any PCN-nodes 📋
6. Backward Compatibility 🫶
BCP 124 [RFC4774] gives guidelines for specifying alternative semantics for the ECN field. It sets out a number of factors to take into consideration, and it suggests various techniques that let default ECN and alternative ECN semantics co-exist. The baseline encoding in this document defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics. So yep, this document is compatible with BCP 124 ✨
On its own, the baseline encoding can't support both ECN marking end-to-end (e2e) and PCN-marking inside a PCN-domain 😭 You can do it by carrying e2e ECN across a PCN-domain within the inner header of an IP-in-IP tunnel, or by using a richer encoding like the proposed experimental scheme in [PCN-ENC] 🎀
In any PCN deployment, traffic can only enter the PCN-domain through PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-nodes make sure any packet entering the PCN-domain has the ECN field in its outermost IP header set to the appropriate PCN codepoint. PCN-egress-nodes then guarantee the ECN field of any packet leaving the PCN-domain has the correct ECN semantics. This stops unintended leakage of ECN marks into or out of the PCN-domain, which cuts down on backward-compatibility issues 🌸
7. Security Considerations 🚨
PCN-marking only carries a meaning within the confines of a PCN-domain. This is serious business, bestie 💀
This encoding document is meant to stand independently of the architecture used to decide how specific packets are authorised to be PCN-marked. That architecture will be described in separate documents on PCN-boundary-node behaviour 🔐
This document assumes the PCN-domain is entirely under the control of a single operator, or a set of operators who trust each other. However, future extensions to PCN might include inter-domain versions where trust can't be assumed between domains. If such schemes are proposed, they must ensure that they can operate securely despite the lack of trust. Those considerations are beyond the scope of this document, though 🙈
One potential security concern is the injection of spurious PCN-marks into the PCN-domain. But these can only get in if a PCN-ingress-node is misconfigured. The precise impact of any such misconfiguration depends on which of the proposed PCN-boundary-node behaviour schemes is used. In general, though, spurious marks lead to admitting fewer flows into the domain, or potentially terminating too many flows 😱 In either case, good management should be able to spot the problem quickly, since the overall utilisation of the domain will rapidly fall 📉
8. Conclusions 👑
This document defines the baseline PCN encoding, using a combination of a PCN-compatible DSCP and the ECN field in the IP header. The baseline encoding allows two PCN encoding states to exist: Not-marked and PCN-marked. It also lets competing traffic co-exist within the same DSCP, as long as that traffic doesn't need ECN support within the PCN-domain. The encoding scheme is conformant with [RFC4774]. The working group chose not to define a single DSCP for PCN, and the rationale for that decision, along with advice on choosing suitable DSCPs, can be found in Appendix A.1 🌈
9. Acknowledgements 🫶
This document builds extensively on work done in the PCN working group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna Charny, Joe Babiarz, and others. Thanks to Ruediger Geib and Gorry Fairhurst for providing detailed comments on this document 💖
10. References 📚
10.1. Normative References 💖
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
- [RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
- [RFC5670] Eardley, P., Ed., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
10.2. Informative References 🌸
- [ECN-TUN] Briscoe, B., "Tunnelling of Explicit Congestion Notification", Work in Progress, July 2009.
- [PCN-ENC] Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding using 2 DSCPs to provide 3 or more states", Work in Progress, April 2009.
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
- [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
- [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
- [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", RFC 5127, February 2008.
- [RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
Appendix A. PCN Deployment Considerations (Informative) 🎀
A.1. Choice of Suitable DSCPs 🦋
okay so the PCN working group deliberately did NOT pick just one DSCP for PCN, and there are three reasons 💅. First, PCN works for a bunch of different traffic classes. Second, Standards Track DSCPs are running out fast 😭. Third, PCN isn't a scheduling behaviour at all. It's more of a marking behaviour, kinda like ECN, but it's meant for inelastic traffic 🫶.
Which DSCP is the best fit depends on two things: the kind of traffic coming into the PCN-domain, and the link rates of every link in that domain. In PCN-domains with enough aggregation, the right DSCPs are currently the ones for the Real-Time Treatment Aggregate [RFC5127] ✨. The working group suggests using admission control for these service classes (defined in [RFC4594]) 💜:
- Telephony (EF)
- Real-time interactive (CS4)
- Broadcast Video (CS3)
- Multimedia Conferencing (AF4)
CS5 is left off this list because PCN isn't expected to be applied to signalling traffic 🙈.
PCN-marking is meant to be a scalable admission-control mechanism for traffic with a high degree of statistical multiplexing 🔥. So PCN-marking would make sense for the classes above, but only inside a PCN-domain with sufficiently aggregated traffic 🌈. In that situation, all of those service classes might get one single forwarding treatment (treatment aggregate [RFC5127]). BUT that doesn't mean all of that IP traffic has to share one DSCP. Each service class might keep its own distinct DSCP inside the highly aggregated region [RFC5127] 🧚.
Extra service classes could also be defined that need admission control, either through some future standards action or through local use by certain operators, like the Multimedia Streaming service class (AF3) 🍓. This document doesn't rule out using PCN in more cases than the ones listed above 🌸.
Note: The above discussion is informative not normative, as operators are ultimately free to decide whether to use admission control for certain service classes and whether to use PCN as their mechanism of choice. 💅
A.2. Rationale for Using ECT(0) for Not-Marked 🫧
So the choice of ECT codepoint for the Not-marked state came down to these considerations 🤔:
- [RFC3168] full-functionality tunnel within the PCN-domain: Either ECT is safe.
- Leakage of traffic into PCN-domain: Because of the lack of take-up of the ECN nonce [RFC3540], leakage of ECT(1) is less likely to occur and so might be considered safer.
- Leakage of traffic out of PCN-domain: Either ECT is equally unsafe (since this would incorrectly indicate the traffic was ECN-capable outside the controlled PCN-domain).
- Incremental deployment: Either codepoint is suitable, providing that the codepoints are used consistently.
- Conceptual consistency with other schemes: ECT(0) is conceptually consistent with [RFC3168].
Overall, this seemed to suggest that ECT(0) was most appropriate to use 👑.
Appendix B. Co-Existence of PCN and ECN (Informative) 🌈
okay bestie, this baseline encoding scheme redefines the ECN codepoints inside the PCN-domain 😭. When packets with a PCN-compatible DSCP leave the PCN-domain, their ECN field gets reset to not-ECT (00). That's a problem for the operator if those packets arrive at the PCN-domain with any ECN codepoint other than not-ECN 💀. If the ECN codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to 00 basically turns off end-to-end ECN. That's not it, because it kills the benefits of ECN, but [RFC3168] says that's no worse than dropping the packet 🥺. HOWEVER, if a packet was marked with CE (11), resetting the ECN field to 00 at the PCN egress node breaks the rule that CE-marks only ever get lost when a packet is dropped [RFC3168] 😱.
There are a bunch of options to fix this 🛠️. The best one depends on the circumstances and is a decision for the operator 💜. Defining the action is beyond the scope of this document, but here are the four broad categories of solution: tunnelling the packets, using an extended encoding scheme, signalling to the end systems to stop using ECN, or re-marking packets to a different DSCP ✨.
- Tunnelling the packets across the PCN-domain (for instance, in an IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node) preserves the original ECN marking on the inner header 🎁.
- An extended encoding scheme can be designed that preserves the original ECN codepoints. For instance, if the PCN-egress-node can determine from the PCN codepoint what the original ECN codepoint was, then it can reset the packet to that codepoint. [PCN-ENC] partially achieves this but is unable to recover ECN markings if the packet is PCN-marked in the PCN-domain 🧩.
- Explicit signalling to the end systems can indicate to the source that ECN cannot be used on this path (because it does not support ECN and PCN at the same time). Dropping the packet can be thought of as a form of silent signal to the source, as it will see any ECT-marked packets it sends being dropped 🤫.
- Packets that are not part of a PCN-flow but which share a PCN-compatible DSCP can be re-marked to a different local-use DSCP at the PCN-ingress-node, with the original DSCP restored at the PCN-egress. This preserves the ECN codepoint on these packets but relies on there being spare local-use DSCPs within the PCN-domain 🍓.
Authors' Addresses 🧚
Toby Moncaster
BT
B54/70, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 7918 901170
EMail: toby.moncaster@bt.com
Bob Briscoe
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
Michael Menth
University of Wuerzburg
Institute of Computer Science
Am Hubland
Wuerzburg D-97074
Germany
Phone: +49 931 318 6644
EMail: menth@informatik.uni-wuerzburg.de📦 where this page comes from
- ietf: rfc5696 2009-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms