Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 4 Apr 2008 10:51:58 +0200

Hi Joe,
 
congratulations, smart engineering.
 
Some initial thoughts:
 
- a PCN policer counts all packets belonging to the EF-admit DSCP. After 
  the lower threshold is passed, a certain type is remarked, after the upper 
  has been passed, all are remarked.
- you mention probing, but I'm not sure we should call it that. We are in 
  agreement, that the RSVP path message must be sent anyway. What 
  we talk about is an encoding option at the ingress and a specific 
  marking behaviour at the core.
 
Two questions:
- is it possible to realise your proposal with a token bucket policer? I guess 
  not, because the policer counts all packets of a certain DSCP, but it 
  modifies only part of all. This seems to resemble the behaviour of a 
  hyrachical policer. Which doesn't have to be bad - its just that hyrachical 
  schedulers aren't a commodity in backbone routers these days.
- the ingress must mark RSVP refresh messages differently than initial 
  messages. I may be wrong, but RSVP refreshes don't look different than 
  initial set up messages. The only difference is, that a node registers state 
  has been set up already. The differentiation is required to avoid an admission 
  stop to result in a termination.
 
Then let's come to one of my favorite subjects, MPLS interoperability. Too bad, 
that doesn't work. You can optimistically squeeze one EXP codepoint from 
the MPLS bunch. So there (and I guess for Ethernet too), an SM proposal 
will be it. That's bad in these networks and shouldn't avoid smarter solutions 
in the IP network.
 
However the friends of MPLS shouldn't be left without a PCN solution. I 
currently can't imagine, how single marking could be downpropagated to an 
IP packet following the above coding scheme in a reasonable way. 
Especially if your backbone works with pen ultimate hop popping of labels.
So in the MPLS case, probably a different solution is required.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Jozef Babiarz
	Sent: Sunday, March 30, 2008 9:10 PM
	To: [email-masked]
	Subject: [PCN] Single DSCP for Admission and Flow Termination Marking

	I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed.

	The proposed approach can use the EF-admit DSCP for PCN.

	My assumptions:

	The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss.

	Proposed encoding:

	A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way:

	ECN = 00, means that packet is not-PCN-capable and that admission control is done some other way.

	Interior nodes remark ECN = "01" packets to "11" if traffic rate is above PCN-lower-rate.

	Interior nodes remark ECN = "10" packets to "11" if traffic rate is above PCN-upper-rate. 

	How it works:

	For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control.

	For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction. 

	The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means. 

	This sounds simple, so what have I missed? 

	This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation.

	I believe that this marking also satisfies guidelines in RFC4774.

	Are there any conditions where this marking approach will not work?

	One final note:

	If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774.

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 10:01:22 +0100

Joe

quick question - in terms of ECN compatibility - is this achieved by
tunnelling over the pcn-domain? 

Thanks

Phil. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jozef Babiarz
Sent: 30 March 2008 20:10
To: [email-masked]
Subject: [PCN] Single DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling problem for PCN and I
think there may be a method by which a single DSCP and the ECN field can
be used to signal both admission control and flow termination using ECN
bits. Would like others to think about this and point out any issues
that I may have missed.

My assumptions:

The EF-admit DSCP is used for end-to-end admission control as proposed
by Fred Baker and the PCN wg also reuses this DSCP for PCN based
admission control and flow termination function for edge-to-edge. Should
note that I believe this can also be used for end-to-end PCN based
admission and termination but this is currently out of scope so I will
not discuss.

Proposed encoding:

A packet that is market with EF-admit DSCP means that it is admission
control with that ECN bits be used in the following way:

ECN = 00, means that packet is not-PCN-capable and that admission
control is done some other way.

Interior nodes remark ECN = "01" packets to "11" if traffic rate is
above PCN-lower-rate.

Interior nodes remark ECN = "10" packets to "11" if traffic rate is
above PCN-upper-rate. 

How it works:

For PCN based admission control this approach requires that "probe"
packet be sent at flow setup to determine if a new flow can be admitted.
Example of a probe packet is a RSVP Path message sent from
ingress-edge-node to egress-edge-node. The RSVP Path packet is market
with EF-admit DSCP and has its ECN bits set to "01". Interior nodes
meter EF-admit packets against the PCN-lower-rate and the result of the
meter is passed to the marker where the marker remarks "01" packet to
"11" if PCN-lower-rate was exceeded. The metering and marking behavior
is the so called "threshold marking" as defined in CL or 3sm drafts for
admission control.

For PCN based flow termination, once a flow is admitted,
ingress-edge-node marks admitted PCN traffic with ECN bits to "10".
Interior nodes meter EF-admit packets against PCN-upper-rate and the
results of the meter is passed to the marker where the maker remarks
"10" packets to "11" based on "excess-rate marking" with or without
marking frequency reduction. 

The egress-edge-node knows if the "11" market packet is a probe or it
belongs to an admitted flow therefore it can interpret what the marking
means. 

This approach works with tunneling, as ECN CE state is copied from outer
to inner IP header on de-encapsulation.

One final note:

If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask
Fred Baker to add a statement in to his draft that the ECN bits in the
IP header are used for other function and that RFC3168 does not apply to
EF-admit DSCP as per guidance in RFC4774.

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 4 Apr 2008 12:42:39 +0200

Hi
 
I am also interested in an answer to this question, and it goes mainly
for all the different encoding options that "fiddle" with the ECN bits
in one way or the other. I have a feeling that tunneling is more or less
the only way to ensure atleast some of the e2e ECN semantics as
described in RFC3168 and RFC4774. However I recall that tunneling has
its fair share of issues (from earlier discussion by Bob Briscoe).
I believe that it would be really helpful if the group could propose how
the e2e ECN semantics is best handled. It need to note be solved now but
should preferrably be solved once the core issues are solved. 
 
I am watching this WG mainly from an application point of view and the
ECN bits can be useful for adaptation purposes in eg. streaming
applications. The details of flow admission/termination are partly above
my head, my main interest is in trying to keep ECN working even across
PCN domains.
 
Regards
/Ingemar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: den 4 april 2008 11:01
To: [email-masked]; [email-masked]
Subject: Re: [PCN] Single DSCP for Admission and Flow Termination
Marking

Joe

Thanks

Phil. 

-----Original Message-----

My assumptions:

Proposed encoding:

How it works:

One final note:

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 6 Apr 2008 00:55:08 -0400

See comments below.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: April 4, 2008 4:52 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] Single DSCP for Admission and Flow Termination
Marking

Hi Joe,

Some initial thoughts:

  the lower threshold is passed, a certain type is remarked, after the
upper 

- you mention probing, but I'm not sure we should call it that. We are
in 

[Joe] I'm OK with not calling it probing.

Two questions:

- is it possible to realise your proposal with a token bucket policer? I
guess 

  hyrachical policer. Which doesn't have to be bad - its just that
hyrachical 

[Joe] Yes it's possible. I have modified a token bucket policer on one
of our routers in the lab to do this type of marking. 

Used one TB for PCN-lower-rate and second TB for PCN-upper-rate.

  initial set up messages. The only difference is, that a node registers
state 

  has been set up already. The differentiation is required to avoid an
admission 

[Joe] I would assume the RSVP refresh message would be sent with the
same ECN markings as the RSVP PATH message. The egress know that this is
RSVP packet (I still think that we should call it probe packet) and that
reflects current traffic level against PCN-lower-rate (admission). 

Then let's come to one of my favorite subjects, MPLS interoperability.
Too bad, 

will be it. That's bad in these networks and shouldn't avoid smarter
solutions 

in the IP network.

[Joe] In MPLS networks, I think that you only need one PCN mechanism and
that is admission control. In my view why do you need flow termination
when you have engineered LSPs with fast-reroute? If you large LSPs SM
works fine.

currently can't imagine, how single marking could be downpropagated to
an 

Especially if your backbone works with pen ultimate hop popping of
labels.

 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jozef Babiarz
	Sent: Sunday, March 30, 2008 9:10 PM
	To: [email-masked]
	Subject: [PCN] Single DSCP for Admission and Flow Termination
Marking

	I was thinking about the encoding and tunneling problem for PCN
and I think there may be a method by which a single DSCP and the ECN
field can be used to signal both admission control and flow termination
using ECN bits. Would like others to think about this and point out any
issues that I may have missed.

	My assumptions:

	The EF-admit DSCP is used for end-to-end admission control as
proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN
based admission control and flow termination function for edge-to-edge.
Should note that I believe this can also be used for end-to-end PCN
based admission and termination but this is currently out of scope so I
will not discuss.

	Proposed encoding:

	A packet that is market with EF-admit DSCP means that it is
admission control with that ECN bits be used in the following way:

	ECN = 00, means that packet is not-PCN-capable and that
admission control is done some other way.

	Interior nodes remark ECN = "01" packets to "11" if traffic rate
is above PCN-lower-rate.

	Interior nodes remark ECN = "10" packets to "11" if traffic rate
is above PCN-upper-rate. 

	How it works:

	For PCN based admission control this approach requires that
"probe" packet be sent at flow setup to determine if a new flow can be
admitted. Example of a probe packet is a RSVP Path message sent from
ingress-edge-node to egress-edge-node. The RSVP Path packet is market
with EF-admit DSCP and has its ECN bits set to "01". Interior nodes
meter EF-admit packets against the PCN-lower-rate and the result of the
meter is passed to the marker where the marker remarks "01" packet to
"11" if PCN-lower-rate was exceeded. The metering and marking behavior
is the so called "threshold marking" as defined in CL or 3sm drafts for
admission control.

	The egress-edge-node knows if the "11" market packet is a probe
or it belongs to an admitted flow therefore it can interpret what the
marking means. 

	This approach works with tunneling, as ECN CE state is copied
from outer to inner IP header on de-encapsulation.

	I believe that this marking also satisfies guidelines in
RFC4774.

	Are there any conditions where this marking approach will not
work?

	One final note:

	If PCN wg decides to reuse the EF-admit DSCP for PCN than we
need to ask Fred Baker to add a statement in to his draft that the ECN
bits in the IP header are used for other function and that RFC3168 does
not apply to EF-admit DSCP as per guidance in RFC4774.

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 6 Apr 2008 00:58:12 -0400

Phil, not sure I understand your question.

ECN traffic is marked with a different DSCP therefore it will not be
subject to this marking treatment. 

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: [email-masked] [mailto:[email-masked]] 
Sent: April 4, 2008 5:01 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] Single DSCP for Admission and Flow Termination
Marking

Joe

Thanks

Phil. 

-----Original Message-----

My assumptions:

Proposed encoding:

How it works:

One final note:

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 6 Apr 2008 01:30:22 -0400

PCN is deployed only in Diffserv network. If PCN wg would like to reuse
the standardized ECN bits to support alternate ECN semantics, than it
should define a new traffic class consistent with RFC3246 and have IANA
assigned a DSCP value.  In the definition of the new traffic class the
PCN semantics is specified. And yes in my mind PCN should be end-to-end
signaling experienced congestion levels.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: Ingemar Johansson S [mailto:[email-masked]] 
Sent: April 4, 2008 6:43 AM
To: [email-masked]; Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] Single DSCP for Admission and Flow Termination
Marking

Hi

Regards

/Ingemar

Joe

Thanks

Phil. 

-----Original Message-----

My assumptions:

Proposed encoding:

How it works:

One final note:

Regards, Joe

email:[email-masked]

Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 6 Apr 2008 20:35:52 -0400

Ruediger,

Are you interested in using PCN in MPLS network? What kind of MPLS
network are you running? Do you need both admission control and flow
termination mechanism and why?

In MPLS network the 3 EXP bits (8 states) can be used to signal
different network treatment. Operators can assign and use the 8 states
as encoding by the 3 EXP bits to indicate that this traffic is
PCN-capable, traffic level is above PCN-lower-rate and/or
PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be
need. The other 5 or 6 encoding states can be used for QoS and ECN.

I have been thinking about PCN in MPLS and have come up with one example
where I think it would be useful.

MPLS Network does not support TE and PCN is used to limit the amount of
traffic that can be admitted. In this example I do not believe that flow
termination would be useful. So on 2 encoding states are needed.

Can someone give me an MPLS example that would benefit from use PCN flow
termination and admission control?

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Babiarz, Jozef (CAR:0S03)
Sent: April 6, 2008 12:55 AM
To: Geib, Ruediger
Cc: [email-masked]
Subject: Re: [PCN] Single DSCP for Admission and Flow Termination
Marking

See comments below.

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

Hi Joe,

Some initial thoughts:

Two questions:

in the IP network.

 

	My assumptions:

	Proposed encoding:

	How it works:

	One final note:

	Regards, Joe

	email:[email-masked]

	Telephone:613-763-6098

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 7 Apr 2008 09:11:10 +0200

Hi Joe,
 
two more statements in line,
 
Rudiger

	From: Geib, Ruediger [mailto:[email-masked]] 
	Sent: April 4, 2008 4:52 AM
	To: Babiarz, Jozef (CAR:0S03)
	Cc: [email-masked]
	Subject: RE: [PCN] Single DSCP for Admission and Flow Termination Marking

	Hi Joe,

	Some initial thoughts:

	Two questions:

	[Joe] Yes it's possible. I have modified a token bucket policer on one of our routers in the lab to do this type of marking. 

	[Joe] I would assume the RSVP refresh message would be sent with the same ECN markings as the RSVP PATH message. The egress know that this is RSVP packet (I still think that we should call it probe packet) and that reflects current traffic level against PCN-lower-rate (admission).  

	[RG] I don't understand the "reflects current traffic level against PCN-lower-rate" statement. Do you mean the sum of the signaled rates as compared to a measured traffic rate by that? 

	in the IP network.

	[Joe] In MPLS networks, I think that you only need one PCN mechanism and that is admission control. In my view why do you need flow termination when you have engineered LSPs with fast-reroute? If you large LSPs SM works fine. 

	[RG] I'm favouring a solution without termination and you are right that I expect traffic engineering to avoid packet loss in the PCN class under regular operational conditions. Long intervals with traffic above the lower threshold should be avoided however. But I'm favouring network to end signaling by passing on CE marked packets to this regard (and I'm aware that you too are supporting network to end signaling by passing on CE marked packets).

	 

		My assumptions:

		Proposed encoding:

		How it works:

		One final note:

		Regards, Joe

		email:[email-masked]

		Telephone:613-763-6098

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 7 Apr 2008 09:28:28 +0200

Hi Joe,
 
I've mentioned that in my other mail, but I'm happy to repeat it here:
 
- the network is running LDP,
- it is engineered to maintain an SLA under regular operational conditions (ie. including single outages),
- all routers are DiffServ enabled.
 
Our backbone engineering departement is extremly careful with assigning additional EXP values for any feature in the core network. As I don't like termination (and I think to recall that someone mentioned it is forbidden in Germany), I'm looking at admission control as the only feature required by PCN. To avoid long term admission stop intervals, I'm favouring to pass on network to end CE marked packets. 
 
If I understand your message right, we are largely in agreement.
 
Regards,
 
Rudiger

	From: Jozef Babiarz [mailto:[email-masked]] 
	Sent: Monday, April 07, 2008 2:36 AM
	To: Jozef Babiarz; Geib, Rüdiger
	Cc: [email-masked]
	Subject: RE: [PCN] PCN in MPLS Network

	Ruediger,

	Are you interested in using PCN in MPLS network? What kind of MPLS network are you running? Do you need both admission control and flow termination mechanism and why?

	In MPLS network the 3 EXP bits (8 states) can be used to signal different network treatment. Operators can assign and use the 8 states as encoding by the 3 EXP bits to indicate that this traffic is PCN-capable, traffic level is above PCN-lower-rate and/or PCN-upper-rate, etc. To support PCN, 2 or 3 out of 8 states would be need. The other 5 or 6 encoding states can be used for QoS and ECN.

	I have been thinking about PCN in MPLS and have come up with one example where I think it would be useful.

	MPLS Network does not support TE and PCN is used to limit the amount of traffic that can be admitted. In this example I do not believe that flow termination would be useful. So on 2 encoding states are needed.

	Can someone give me an MPLS example that would benefit from use PCN flow termination and admission control?

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Babiarz, Jozef (CAR:0S03)
	Sent: April 6, 2008 12:55 AM
	To: Geib, Ruediger
	Cc: [email-masked]
	Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking

	See comments below.

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	Hi Joe,

	Some initial thoughts:

	Two questions:

	in the IP network.

	 

		My assumptions:

		Proposed encoding:

		How it works:

		One final note:

		Regards, Joe

		email:[email-masked]

		Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 7 Apr 2008 22:08:47 -0400

Ruediger, see further explanations in line,  

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: April 7, 2008 3:11 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] Single DSCP for Admission and Flow Termination
Marking

Hi Joe,

Rudiger

	From: Geib, Ruediger [mailto:[email-masked]] 
	Sent: April 4, 2008 4:52 AM
	To: Babiarz, Jozef (CAR:0S03)
	Cc: [email-masked]
	Subject: RE: [PCN] Single DSCP for Admission and Flow
Termination Marking

	Hi Joe,

	Some initial thoughts:

	- a PCN policer counts all packets belonging to the EF-admit
DSCP. After 

	  the lower threshold is passed, a certain type is remarked,
after the upper 

	- you mention probing, but I'm not sure we should call it that.
We are in 

	  agreement, that the RSVP path message must be sent anyway.
What 

	  we talk about is an encoding option at the ingress and a
specific 

	Two questions:

	- is it possible to realise your proposal with a token bucket
policer? I guess 

	  not, because the policer counts all packets of a certain DSCP,
but it 

	  modifies only part of all. This seems to resemble the
behaviour of a 

	  hyrachical policer. Which doesn't have to be bad - its just
that hyrachical 

	[Joe] Yes it's possible. I have modified a token bucket policer
on one of our routers in the lab to do this type of marking. 

	- the ingress must mark RSVP refresh messages differently than
initial 

	  messages. I may be wrong, but RSVP refreshes don't look
different than 

	  initial set up messages. The only difference is, that a node
registers state 

	  has been set up already. The differentiation is required to
avoid an admission 

	[Joe] I would assume the RSVP refresh message would be sent with
the same ECN markings as the RSVP PATH message. The egress know that
this is RSVP packet (I still think that we should call it probe packet)
and that reflects current traffic level against PCN-lower-rate
(admission).  

	[RG] I don't understand the "reflects current traffic level
against PCN-lower-rate" statement. Do you mean the sum of the signaled
rates as compared to a measured traffic rate by that? 

	[Joe] My assumption is that PCN-lower-rate marked use
"Threshold" marking behavior as outlined by Phil Eardley's presentation,
therefore anytime RSVP PATH or RSVP refresh packet is sent, the egress
will know the current status of traffic along the path. If the traffic
level is below PCN-lower-rate the packet will not be marked, but if it
is above packet is marked. There is no need to perform any rate
measurements in the egress or ingress for admission control. 

	Then let's come to one of my favorite subjects, MPLS
interoperability. Too bad, 

	that doesn't work. You can optimistically squeeze one EXP
codepoint from 

	the MPLS bunch. So there (and I guess for Ethernet too), an SM
proposal 

	will be it. That's bad in these networks and shouldn't avoid
smarter solutions 

	in the IP network.

	[Joe] In MPLS networks, I think that you only need one PCN
mechanism and that is admission control. In my view why do you need flow
termination when you have engineered LSPs with fast-reroute? If you
large LSPs SM works fine. 

	[RG] I'm favouring a solution without termination and you are
right that I expect traffic engineering to avoid packet loss in the PCN
class under regular operational conditions. Long intervals with traffic
above the lower threshold should be avoided however. But I'm favouring
network to end signaling by passing on CE marked packets to this regard
(and I'm aware that you too are supporting network to end signaling by
passing on CE marked packets).

	[Joe] Yes. I support that PCN marking or CE be passed to
endpoint. 

	However the friends of MPLS shouldn't be left without a PCN
solution. I 

	currently can't imagine, how single marking could be
downpropagated to an 

	Especially if your backbone works with pen ultimate hop popping
of labels.

	 

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jozef Babiarz
		Sent: Sunday, March 30, 2008 9:10 PM
		To: [email-masked]
		Subject: [PCN] Single DSCP for Admission and Flow
Termination Marking

		I was thinking about the encoding and tunneling problem
for PCN and I think there may be a method by which a single DSCP and the
ECN field can be used to signal both admission control and flow
termination using ECN bits. Would like others to think about this and
point out any issues that I may have missed.

		My assumptions:

		The EF-admit DSCP is used for end-to-end admission
control as proposed by Fred Baker and the PCN wg also reuses this DSCP
for PCN based admission control and flow termination function for
edge-to-edge. Should note that I believe this can also be used for
end-to-end PCN based admission and termination but this is currently out
of scope so I will not discuss.

		Proposed encoding:

		A packet that is market with EF-admit DSCP means that it
is admission control with that ECN bits be used in the following way:

		Interior nodes remark ECN = "01" packets to "11" if
traffic rate is above PCN-lower-rate.

		Interior nodes remark ECN = "10" packets to "11" if
traffic rate is above PCN-upper-rate. 

		How it works:

		For PCN based admission control this approach requires
that "probe" packet be sent at flow setup to determine if a new flow can
be admitted. Example of a probe packet is a RSVP Path message sent from
ingress-edge-node to egress-edge-node. The RSVP Path packet is market
with EF-admit DSCP and has its ECN bits set to "01". Interior nodes
meter EF-admit packets against the PCN-lower-rate and the result of the
meter is passed to the marker where the marker remarks "01" packet to
"11" if PCN-lower-rate was exceeded. The metering and marking behavior
is the so called "threshold marking" as defined in CL or 3sm drafts for
admission control.

		The egress-edge-node knows if the "11" market packet is
a probe or it belongs to an admitted flow therefore it can interpret
what the marking means. 

		This approach works with tunneling, as ECN CE state is
copied from outer to inner IP header on de-encapsulation.

		Are there any conditions where this marking approach
will not work?

		One final note:

		If PCN wg decides to reuse the EF-admit DSCP for PCN
than we need to ask Fred Baker to add a statement in to his draft that
the ECN bits in the IP header are used for other function and that
RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774.

		Regards, Joe

		email:[email-masked]

		Telephone:613-763-6098

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 7 Apr 2008 22:40:39 -0400

Hi Ruediger,

My point that I was trying to make is that, I believe that only admission control will be useful in MPLS network, therefore in MPLS networks only two encoding will be used. 

However, in IP networks, I believe that flow termination will be useful and defining a marking method using ECN bits and a single DS codepoint that can support reliably admission control and flow termination in most deployments is what the workgroup should be striving for. I do not agree with the notion that we can not have marking method for admission control and one for flow termination (3 states) and the only way forward is single marking approach (2 states).

Regards, Joe 
email:[email-masked] 
Telephone:613-763-6098 

From: Geib, Ruediger [mailto:[email-masked]] 
Sent: April 7, 2008 3:28 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] PCN in MPLS Network

Hi Joe,

Regards,

Rudiger

	Ruediger,

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	See comments below.

	Regards, Joe 
	email:[email-masked] 
	Telephone:613-763-6098 

	Hi Joe,

	Some initial thoughts:

	Two questions:

	in the IP network.

	 

		My assumptions:

		Proposed encoding:

		How it works:

		One final note:

		Regards, Joe

		email:[email-masked]

		Telephone:613-763-6098