Subject: [Ieprep] proposed charter

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 01:21:39 -0400

Two people sent me private email pointing to the email message with
the proposed charter.

http://www1.ietf.org/mail-archive/web/ieprep/current/msg02421.html

Thanks.

Seems mostly reasonable to me.  One paragraph seems open ended and may
be a source of trouble for other reasons.

  If there is an existing group that can extend a protocol or
  mechanism, IEPREP will generate only a requirements document for
  those groups to evaluate. If there is not an existing group that can
  extend a protocol or mechanism, IEPREP will prepare requirements and
  discuss the extension of that protocol/mechanism or
  protocols/mechanisms within IEPREP.

This is a promise to liason with anybody and everbody that intends to
work in this area and to step back and let that other group do the
protocol work.  The IESG favors (with good reason) WG charters that
propose to do work rather than WG charters that propose to sit back
and watch the ITU do work in that area.  A good example (and closely
related to this sort of work) where the result coming from the ITU was
not at all useful is the ITU QoS requirements work in the mid to late
1990s.  This may be looking too much like more of the same.

This is off topic for a charter discussion but please bear with me.
If anyone responds to this part of the email, consider changing the
subject.  I'm getting way out ahead of the "requirements first, then
solutions" process but the way I envision ETS working is as follows.

SIP and microflow RSVP control flow must preceed traffic flow.  SIP is
seen only at ingress and egress.  Microflow RSVP is seen only by
SIP/RSVP gateways at ingress, egress, and provider boundaries.  Within
a provider's core, both the microflow RSVP control traffic and the
actual traffic is typically carried within MPLS signaled with RSVP/TE,
although this is entirely up to the provider (they are free to use
edge-to=-edge microflow RSVP if they prefer).  If MPLS/TE is used then
the reservation reflects the sum of microflow RSVP reservations but
the microflow reservations are seen only at provider boundaries.
SIP/uflow-RSVP gateway addresses can/should be assigned such that at
provider boundaries the control traffic can be diverted to dedicated
SIP/RSVP capable hardware rather than put this function on the
provider IP peering routers.

Traffic is marked with DSCP marking across providers but within
providers is typically carried in MPLS.  If the number of priorities
is small (possibly true for early deployments) then it may simplify
deployment.  There are only a few IP-Prec values available (some are
already used for network control traffic).  EF has only one value at
this point.  AF has 4 AF classes with 3 drop preferences in each and
seems to be the most likely candidate but leaves no room for AF
services of less importance than ETS such as commercial VPN.  If the
number of priorities is small it may be sufficient to use a DSCP to
EXP mapping.  Otherwise, a full Diffserv-TE implementation may be
needed.

As long as the number of priority/preemption classes remains too open
ended, the mapping onto DSCP and Diffserv-TE remains uncertain.  For
example, there has to be a strong technical justification for five
priority classes, not just "because ITU specified five" before there
is much of a chance for a set of new DSCP values to be assigned as
anything other than experimental.

Note that there is nothing wrong with using a set of experimental DSCP
values, even in early deployments.  If multiple providers use these a
set of DSCP values can be assigned in the non-experimental space with
identical semantics and then later the experimental DSCP depricated
when no longer used (and then reused by the next grand experiment).
If no one ever uses some of the values assigned as experimental, then
they can be depricated without replacements.  Writing new code is work
but changing to a new set of constants is not very hard.  You know -
running code and all that...

Any effort which requires the whole world to agree before getting
started will never get started.

Curtis

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: ken carlberg <[email-masked]>
Date: Tue, 26 Sep 2006 08:47:14 -0400

> 1990s.  This may be looking too much like more of the same.

I don't believe the intention was for IEPREP to rubber stamp work  
from other groups, and we can fix the passage to stress that IEPREP  
would discuss and consider efforts from other groups.   I think there  
is a bit more strength in having an existing set defined by another  
group (and stronger if deployed), then in having a new set specified  
from scratch.  Others may disagree.  But again, strength shouldn't  
correlate to automatic acceptance.

> anything other than experimental.

yes, a good point.  one thing to take note of is that there are  
several installed deployments of the "five" specified by ITU (and  
other groups).  one example can be found in land mobile radio used by  
first responders and specified by APCO on their Project 16 and  
Project 25 efforts.  Another is the MLPP work from ITU and deployed  
in systems like Autovon by DoD, NATO, and some others.  There is also  
the "five" found in cellular networks in the UK and in WPS in the US.

In looking at these deployments, one will notice that the five are  
pretty much in the form of role-based priorities, where the priority  
is assigned based on the role of the user (executive leader,  
battalion chief, etc).  Where older historic systems like Autodin  
rely on content-based prioritization is based on the importance of  
the content of the data being sent regardless of the role of the  
user.  Its easier to implement role-based instead of content-based  
prioritization.

There are some other examples, but a question arises of whether its  
productive to have 5 pushed down into a one-to-one mapping at the IP  
layer in the form of DSCPs given the limited number of bits to work  
with.  One expired draft advocated this direct mapping, while  
RFC-4542 makes an argument for a different approach.  In either case,  
the headache is compounded if other organizations raise the number  
from 5 to 7, 9, 15(?).

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 26 Sep 2006 09:44:40 -0400

As RFC 4412 makes perfectly clear, the RPH serves a dual role of signalling
priority across an IP network (e.g. from an originating circuit switched
access network to a terminating circuit switched access network) as well as
signalling  priority within the IP network.

For each of the namespaces described in RFC 4412, the number of priority
values (5 in most cases, 6 in one) is driven by the former role, based on
the number of priority values in use, or being considered, in the access
network priority scheme.

The issue of how many priority levels to differentiate WITHIN the IP
network is an issue currently being addressed by vendors and providers.

Janet

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 11:43:17 -0400

Thanks.

btw- Defined for SS7 doesn't mean a good fit for SIP and IP.  Lets not
make others lack of foresight IETF's problem if it can be avoided.

> the headache is compounded if other organizations raise the number  

If priority and preemption can be accomplished at the admission level
(SIP and/or microflow RSVP level) then it may be that policing and the
existing EF is sufficient.  Its only where insufficient bandwidth is
allocated and carved into categories and adaptive elastic services are
carried is something like AF needed.  None of the above existing
examples fit the latter category.  It would be nice though if one more
first responder needed to communicate that flow was not blocked but
service quality for some dropped to a more efficient but slightly less
clear audio compression.  Currently that is not possible in any of the
above deployments (afaik).

The EF service is currently unused by most if not all providers.
Since policing and EF would work fine for a capability analogous to
existing services it may be a good start.  If there is a chance of
using an AF like class of service it would certainly be above and
beyond what is provided in PSTN or cellular and could start out as
experimental.  RFC4542 seems to discuss using EF but doesn't seem to
recommend this.

Curtis

---

From: ken carlberg <[email-masked]>
Date: Tue, 26 Sep 2006 11:19:17 -0400

> above deployments (afaik).

true.  one effort that may compliment what you are looking for is a  
draft being advanced in TSVWG, involving a proposed extension to  
RSVP.  In the following draft, the appendix presents several  
potential modes of operation, one of which focuses on carefully  
engineered capacity.
http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 
rsvp-02.txt

there is also a new BoF titled Pre-Congestion Notification (PCN)  
scheduled for San Diego that also touches on what you bring up in  
your last sentence above.  The BoF stems from several related drafts  
discussed in TSVWG including the architecture draft of:

http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl- 
architecture-03.txt
(a cast of thousands :)

along with a problem statement that has been discussed on the PCN list
http://www.ietf.org/internet-drafts/draft-chan-pcn-problem- 
statement-00.txt
with updated issues list leading to the meeting
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt

PCN mailing list: https://www1.ietf.org/mailman/listinfo/pcn

-ken

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 12:56:15 -0400

> network is an issue currently being addressed by vendors and providers.

Janet,

You are right, but you may be just focusing on SIP which is one peice
of the puzzle.

RFC 4412 does not make it perfectly clear whether we need 1 DSCP code
point, EF, or 5 DSCP code points (IP Prec 0-4?)  or 15 DSCP code
points (the 4 AF classes plus one more AF class.  Or is it some
multiple of 6?  This RFC doesn't even mention DSCP.

I'm sorry but this may be my mistake in that when I'm thinking of
priority and preemption I'm not sure based on reading the many things
written about ETS whether we are talking about just 5 SIP classes and
maybe 5 microflow RSVP classes (to be defined?) or 5 classes of AF
service carrying non-SIP traffic (where diffserv only defines 4).

I'm still not sure if IEPREP is calling for 1 or 5 or 6 or 15 or 18
new DSCP code points, or 0 (best answer IMHO).  I suspect that
anything more than what is now defined will be experimental for a
while, until deployed.  This also impacts whether providers using MPLS
within the AS need to deploy a full diffserv-TE implementation.  SIP
and MPLS/TE might be all that is needed in an intra-provider ETS
deployment.  Microflow RSVP might be needed if the SIP GW and MPLS/TE
ingress are not the same box and the amount of bandwidth allocated to
the ETS is not fixed but is allocated on demand but otherwise no.  SIP
(RFC4412) seems to assume a policy server in the sky to be defined
later that will assure that the bandwidth is available.

Whether this traffic crosses AS boundaries may impact whether
microflow RSVP is needed to carry the requirements across AS
boundaries.  I don't think inter-AS RSVP/TE is anywhere close to
reality at this point.  Microflow RSVP across a dedicated (maybe
tunnelled) inter-AS interface may be more palitable and covers
non-VOIP/non-SIP services.

The real challenge is making an ETS work in the real world where a
natural disaster (or worse) has taken out a good part of the physical
infrastructure.  The solution may need to adapt to whatever level of
infrastructure is left.  A fixed allocation and a largely static
configuration might not work at all under those circumstances.  The
ETS has to work as best as possible within the disaster area.  That is
part of what we are trying to accomplish I hope.

Curtis

---

From: ken carlberg <[email-masked]>
Date: Tue, 26 Sep 2006 12:40:17 -0400

Curtis,

rfc-4190 does touch upon some of the points you bring up below.

as for the group advocating a specific set of DSCP code points (new  
or current) in support of ETS, your impression is correct that IEPREP  
has not done so.  this is because that would have been considered a  
specific solution, which has been out of bounds of the group.  Hence  
the interest in modifying the charter.

-ken

On Sep 26, 2006, at 12:56 PM, Curtis Villamizar wrote:

>
> In message <OFBAA95066.05652C8C- 
> [email-masked]>
> Janet P Gunn writes:
>>
>>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2006 14:11:10 -0400

> http://www.ietf.org/internet-drafts/draft-lefaucheur-emergency- 

Thanks.  Saw that but forgot about it.  It does have the microflow
RSVP signaling defined.

The RSVP/TE signaling would be through the provider core and would
support an aggregate of microflows.  A make-before-break reroute could
accomodate an increase in the sum of microflow approaching what was
already allocated.  Failure to find bandwidth to accomodate an
increase could then affect admission and trigger preemption.

That would work in a network in which some of the resources were no
longer available due to natural disaster (or whatever).

> PCN mailing list: https://www1.ietf.org/mailman/listinfo/pcn

PCN seems to assume an MPLS/TE free network.  Not everyone is making
that assumption.

Section 6.7 of draft-briscoe-tsvwg-cl-architecture-03.txt makes the
same suggestion that I've made above.  Earlier it indicates that PCN
or MPLS/TE can be alternatives or combined with MPLS-ECN (though I'm
not sure who supports this).

My impression is that some large ISPs don't want microflow RSVP in the
core and would rather carry it inside MPLS/TE tunnels.  The ingresss
to the MPLS/TE tunnel would have to be microflow RSVP capable but
could be a dedicated router adjacent to a SIP gateway for ETS if there
was any concern that microflow RSVP would pose a problem.

> -ken

The great thing about standards is there are so many to choose from.
:-)

Thanks again for the enlightenning reply,

Curtis

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 26 Sep 2006 17:25:06 -0400

Curtis Villamizar <[email-masked]> wrote on 09/26/2006 12:56:15 PM:

> In message
<[email-masked]>
>...
Since 4412 is a SIP document, it would not be appropriate for it to specify
DSCPs.

However, it does say
" While the 'Resource-Priority' header field does not directly
   influence the forwarding behavior of IP routers or the use of
   communications resources such as packet forwarding priority,
   procedures for using this header field to cause such influence may be
   defined in other documents."
which clearly refers to things such as DSCP.

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 26 Sep 2006 17:26:40 -0400

..
> part of what we are trying to accomplish I hope.

Agreed.