draft-ietf-pcn-baseline-encoding-06.txt		draft-ietf-pcn-baseline-encoding-07.txt
	Congestion and Pre Congestion T. Moncaster		Congestion and Pre Congestion T. Moncaster
	Internet-Draft B. Briscoe		Internet-Draft B. Briscoe
	Intended status: Standards Track BT		Intended status: Standards Track BT
	Expires: March 8, 2010 M. Menth		Expires: March 29, 2010 M. Menth
	University of Wuerzburg		University of Wuerzburg
	September 4, 2009		September 25, 2009
	Baseline Encoding and Transport of Pre-Congestion Information		Baseline Encoding and Transport of Pre-Congestion Information
	draft-ietf-pcn-baseline-encoding-06		draft-ietf-pcn-baseline-encoding-07
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 March 8, 2010.		This Internet-Draft will expire on March 29, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 31		skipping to change at page 2, line 31
	encoding described here provides only two PCN encoding states: not-		encoding described here provides only two PCN encoding states: not-
	marked and PCN-marked. Future extensions to this encoding may be		marked and PCN-marked. Future extensions to this encoding may be
	needed in order to provide more than one level of marking severity.		needed in order to provide more than one level of marking severity.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6		3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6
	3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7		3.1. List of Abbreviations . . . . . . . . . . . . . . . . . . 7
	4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 7		4. Encoding two PCN States in IP . . . . . . . . . . . . . . . . 8
	4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 8		4.1. Marking Packets . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 8		4.2. Valid and Invalid Codepoint Transitions . . . . . . . . . 9
	4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 9		4.3. Rationale for Encoding . . . . . . . . . . . . . . . . . . 10
	4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10		4.4. PCN-Compatible Diffserv Codepoints . . . . . . . . . . . . 10
	4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 10		4.4.1. Co-existence of PCN and not-PCN traffic . . . . . . . 11
	5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11		5. Rules for Experimental Encoding Schemes . . . . . . . . . . . 11
	6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11		6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13		11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 13
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 13		12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	12.2. Informative References . . . . . . . . . . . . . . . . . . 13		12.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. PCN Deployment Considerations (Informational) . . . . 14		Appendix A. PCN Deployment Considerations (Informational) . . . . 15
	A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 14		A.1. Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 15
	A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 15		A.2. Rationale for Using ECT(0) for Not-marked . . . . . . . . 16
			Appendix B. Co-existence of PCN and ECN (Informational) . . . . . 17
	1. Introduction		1. Introduction
	The objective of the Pre-Congestion Notification (PCN) Architecture		The objective of the Pre-Congestion Notification (PCN) Architecture
	[RFC5559] is to protect the quality of service (QoS) of inelastic		[RFC5559] is to protect the quality of service (QoS) of inelastic
	flows within a Diffserv domain, in a simple, scalable and robust		flows within a Diffserv domain, in a simple, scalable and robust
	fashion. The overall rate of the PCN-traffic is metered on every		fashion. The overall rate of the PCN-traffic is metered on every
	link in the PCN-domain, and PCN-packets are appropriately marked when		link in the PCN-domain, and PCN-packets are appropriately marked when
	certain configured rates are exceeded. These configured rates are		certain configured rates are exceeded. These configured rates are
	below the rate of the link thus providing notification before any		below the rate of the link thus providing notification before any
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	header by re-using the bits of the Explicit Congestion Notification		header by re-using the bits of the Explicit Congestion Notification
	(ECN) field [RFC3168]. It also describes how packets are identified		(ECN) field [RFC3168]. It also describes how packets are identified
	as belonging to a PCN-flow. Some deployment models require two PCN		as belonging to a PCN-flow. Some deployment models require two PCN
	encoding states, others require more. The baseline encoding		encoding states, others require more. The baseline encoding
	described here only provides for two PCN encoding states. However		described here only provides for two PCN encoding states. However
	the encoding can be easily extended to provide more states. Rules		the encoding can be easily extended to provide more states. Rules
	for such extensions are given in Section 5.		for such extensions are given in Section 5.
	Changes from previous drafts (to be removed by the RFC Editor):		Changes from previous drafts (to be removed by the RFC Editor):
			From -06 to -07:
			Changes made following IESG review comments.
			Changed Section 4 and added Appendix B to clarify the correct
			behaviour when handling packets that already have values other
			than not-ECT in their ECN field.
			Added paragraph to end of Section 6 clarifying that a PCN-domain
			has "hard" edges.
	From -05 to -06:		From -05 to -06:
	Extensive changes to the text following IETF Last Call and Gen-ART		Extensive changes to the text following IETF Last Call and Gen-ART
	review comments.		review comments.
	Abstract updated following mailing list discussions after Gen-ART		Abstract updated following mailing list discussions after Gen-ART
	review by Spencer Dawkins.		review by Spencer Dawkins.
	Added list of abbreviations		Added list of abbreviations
	skipping to change at page 4, line 11		skipping to change at page 4, line 23
	Section 5. Removed any ambiguity about meaning of PCN-marked in		Section 5. Removed any ambiguity about meaning of PCN-marked in
	such a context. Added requirements for experimental schemes to		such a context. Added requirements for experimental schemes to
	define which meter causes which mark.		define which meter causes which mark.
	Clarified text in Section 6 relating to support for e2e ECN.		Clarified text in Section 6 relating to support for e2e ECN.
	Added text in Section 8 relating to injection of PCN-marks into		Added text in Section 8 relating to injection of PCN-marks into
	the PCN-domain.		the PCN-domain.
	Changed text of Appendix A.1 to reflect comments from Spencer		Changed text of Appendix A.1 to reflect comments from Spencer
	Dawkins and Philip Eardey.		Dawkins and Philip Eardley.
	From -04 to -05:		From -04 to -05:
	Clarified throughout that the PCN WG is not requesting a specific		Clarified throughout that the PCN WG is not requesting a specific
	DSCP for PCN. Rather we are recommending a set of DSCPs that		DSCP for PCN. Rather we are recommending a set of DSCPs that
	might be suitable. Appendix A.1 has been re-written to reflect		might be suitable. Appendix A.1 has been re-written to reflect
	this. References to maintaining a list of PCN-compatible DSCPs		this. References to maintaining a list of PCN-compatible DSCPs
	have also been removed.		have also been removed.
	Last sentence of Section 6 altered.		Last sentence of Section 6 altered.
	skipping to change at page 8, line 16		skipping to change at page 8, line 39
	The following rules apply to all PCN traffic:		The following rules apply to all PCN traffic:
	o PCN-traffic MUST be marked with a PCN-compatible Diffserv		o PCN-traffic MUST be marked with a PCN-compatible Diffserv
	Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be		Codepoint. To conserve DSCPs, Diffserv Codepoints SHOULD be
	chosen that are already defined for use with admission controlled		chosen that are already defined for use with admission controlled
	traffic. Appendix A.1 gives guidance to implementors on suitable		traffic. Appendix A.1 gives guidance to implementors on suitable
	DSCPs. Guidelines for mixing traffic-types within a PCN-domain		DSCPs. Guidelines for mixing traffic-types within a PCN-domain
	are given in [I-D.ietf-pcn-marking-behaviour].		are given in [I-D.ietf-pcn-marking-behaviour].
	o Any packet that is not-PCN but which shares the same Diffserv		o Any packet arriving at the PCN-ingress that shares a PCN-
	codepoint as PCN-enabled traffic MUST have its ECN field set to		compatible DSCP and is not-PCN MUST be marked as not-PCN within
	00.		the PCN-domain.
			o If a packet arrives at the PCN-ingress 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 such packets. However this is
			a drastic action that an operator may feel is undesirable.
			Appendix B provides more information and summarises other
			alternative actions that might be taken.
	4.1. Marking Packets		4.1. Marking Packets
	[I-D.ietf-pcn-marking-behaviour] states that any encoding scheme		[I-D.ietf-pcn-marking-behaviour] states that any encoding scheme
	document must specify the required action to take if one of the		document must specify the required action to take if one of the
	marking algorithms indicates that a packet needs to be marked. For		marking algorithms indicates that a packet needs to be marked. For
	the baseline encoding scheme the required action is simply as		the baseline encoding scheme the required action is simply as
	follows:		follows:
	o If a marking algorithm indicates the need to mark a PCN-packet		o If a marking algorithm indicates the need to mark a PCN-packet
	skipping to change at page 12, line 5		skipping to change at page 12, line 32
	The baseline encoding specified in this document defines PCN-		The baseline encoding specified in this document defines PCN-
	compatible Diffserv codepoints as no longer supporting the default		compatible Diffserv codepoints as no longer supporting the default
	ECN semantics. As such this document is compatible with BCP 124.		ECN semantics. As such this document is compatible with BCP 124.
	On its own, this baseline encoding cannot support both ECN marking		On its own, this baseline encoding cannot support both ECN marking
	end to end and PCN marking within a PCN-domain. It is possible to do		end to end and PCN marking within a PCN-domain. It is possible to do
	this by carrying e2e ECN across a PCN domain within the inner header		this by carrying e2e ECN across a PCN domain within the inner header
	of an IP in IP tunnel, or by using a richer encoding such as the		of an IP in IP tunnel, or by using a richer encoding such as the
	proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].		proposed experimental scheme in [I-D.ietf-pcn-3-state-encoding].
			In any PCN deployment, traffic can only enter the PCN-Domain through
			PCN-ingress-nodes and leave through PCN-egress-nodes. PCN-ingress-
			nodes ensure that any packets entering the PCN- domain have the ECN-
			field in their outermost IP header set to the appropriate PCN
			codepoint. PCN-egress-nodes then guarantee that the ECN-field of any
			packet leaving the PCN-domain has the correct ECN semantics. This
			prevents leakage of ECN marks into or out of the PCN-domain and thus
			reduces backward compatibility issues.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request to IANA.		This document makes no request to IANA.
	8. Security Considerations		8. Security Considerations
	PCN-marking only carries a meaning within the confines of a PCN-		PCN-marking only carries a meaning within the confines of a PCN-
	domain. This encoding document is intended to stand independently of		domain. This encoding document is intended to stand independently of
	the architecture used to determine how specific packets are		the architecture used to determine how specific packets are
	authorised to be PCN-marked, which will be described in separate		authorised to be PCN-marked, which will be described in separate
	skipping to change at page 16, line 24		skipping to change at page 17, line 13
	outside the controlled PCN-domain).		outside the controlled PCN-domain).
	o Incremental deployment: Either codepoint is suitable providing		o Incremental deployment: Either codepoint is suitable providing
	that the codepoints are used consistently.		that the codepoints are used consistently.
	o Conceptual consistency with other schemes: ECT(0) is conceptually		o Conceptual consistency with other schemes: ECT(0) is conceptually
	consistent with [RFC3168].		consistent with [RFC3168].
	Overall this seemed to suggest ECT(0) was most appropriate to use.		Overall this seemed to suggest ECT(0) was most appropriate to use.
			Appendix B. Co-existence of PCN and ECN (Informational)
			This baseline encoding scheme redefines the ECN codepoints within the
			PCN-domain. As packets with a PCN-compatible DSCP leave the PCN-
			domain, their ECN field is reset to not-ECT (00). This is a problem
			for the operator if packets with a PCN-compatible DSCP 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 effectively turns off end-to-end ECN. This is undesirable as it
			removes the benefits of ECN but [RFC3168] states it is 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 violates the
			rule that CE-marks must never be lost except as a result of packet
			drop [RFC3168].
			A number of options exist to overcome this issue. The most
			appropriate option will depend on the circumstances and has to be a
			decision for the operator. The definition of the action is beyond
			the scope of this document but we briefly explain the four broad
			categories of solution below: 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.
			o 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.
			o 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.
			[I-D.ietf-pcn-3-state-encoding] partially achieves this but is
			unable to recover ECN markings if the packet is PCN-marked in the
			PCN-domain.
			o 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 & 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.
			o Packets that are not-PCN 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 the packets, but it relies on there being
			spare local-use DSCPs within the PCN-domain.
	Authors' Addresses		Authors' Addresses
	Toby Moncaster		Toby Moncaster
	BT		BT
	B54/70, Adastral Park		B54/70, Adastral Park
	Martlesham Heath		Martlesham Heath
	Ipswich IP5 3RE		Ipswich IP5 3RE
	UK		UK
	Phone: +44 1473 648734		Phone: +44 1473 648734
End of changes. 14 change blocks.
	22 lines changed or deleted		98 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/