Re: liason & the 5 priorities

In message <[email protected]>
ken carlberg writes:
>  
> > 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).
>  
> 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

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).

> 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

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