Brian,
I think this is the make or break question for the whole current flow label
discussion:
Has the validity of the scenario you describe (MF-classification between
diffserv ISPs) been discussed somewhere?
Some specific questions:
(model: sender -> ... -> upstream ISP -> downstream ISP -> ... -> receiver)
Q1: Why couldn't the ISP's agree on the DSCP-to-PHB mapping (SLA, "off-line
signaling"), with the downstream ISP policing the traffic to the SLA (and
possibly remarking)?
Q2: Why the downstream ISP would not "believe" the DSCP value, but would
believe the flow label value?
Q3: Presumably the upstream ISP is transmitting traffic originated by his
customers, so the upstream ISP has no control of the transport protocols and
port numbers being transmitted. WHY would an SLA between two ISPs be based
on port numbers (MF-classification) set by a third party (the packet
originator)?
I see that the problem you have in the diffserv architecture is that the
DSCP values are meaningless outside a diffserv domain, and that you'd like
to utilize the flow-label field to carry the globally unique identifier of
the PHB. IMO, this would be MUCH better than any traditional micro-flow
MF-classification in the context of diffserv.
But what I fail to understand is that, since SLAs between ISPs are needed
anyway to specify the policy for each traffic aggregate (however the
classification is done), why couldn't the DSCP->PHB mapping be a part of the
same SLA?
In this model there would be NO question of anyone "believing" any values,
as the downstream ISP would NOT CARE what any of the header values are, as
all the traffic would be policed to the SLA, regardless of the actual
contents of any headers above the IP header. It would be the responsibility
of the upstream ISP to (re-)mark the DSCPs in the packets to get the best
utilization of the SLA.
IMO this would also be the most performance efficient method for all parties
involved.
Jarno
Brian wrote:
> The issue is that if the packet is classified prior to being
> encrypted, what do you do if a downstream ISP declines to
> believe the classification (DCSP value) and wishes to reclassify
> the packet? The proposal is to put enough semantics in the flow
> label to allow some degree of classification.
>
> Brian
>
> Michael Thomas wrote:
> >
> > Bill Sommerfeld writes:
> > > > Huh? I thought that one of the requirements for ESP was to
> > > > copy the DSCP to the outer header. If I recall correctly,
> > > > this bothers some people from a traffic analysis standpoint,
> > > > but that seems to be part and parcel with QoS so
> that doesn't
> > > > hold much water IMO.
> > >
> > > It seems that it would be appropriate for an implementation to
> > > "reclassify" packets at the time of encapsulation into ESP -- the
> > > packet is, after all, going through a logical trust
> boundary as it's
> > > being encrypted..
> >
> > If I understand Brian's concern correctly, that may
> > not necessarily be the case. The security gateway may
> > be on egress from my network and hence controlled by me.
> > If the service provider wants to reclassify those packets,
> > it would need to be done at the next hop router from the
> > security gateway (ie on a router they controlled).
> >
> > I'm still not sure I understand the policing they are
> > trying to accomplish though; it seems sort of weird
> > to have port level classification on the other side of the
> > trust boundary to set the proper DSCP, unless it's just
> > provide a service that could (should?) have been done at
> > your egress router. Otherwise it seems like
> > the user would be shooting themselves in the foot since
> > the normal method is for the policer to police to a
> > certain SLA on a given aggregate traffic class. This
> > to my mind would argue for the classification to be
> > done on *before* it is encapsulated with ESP, but the
> > policing done on the aggregate where it doesn't care
> > about the port data.
> >
> > Ie:
> >
> > luserdata------------>SG---------------------->AR
> > (classifies, (polices
> > remarks dscp, SLA against
> > encrypts) DSCP, remarks)
> >
> > Mike
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page: http://playground.sun.com/ipng
> > FTP archive: ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to [EMAIL PROTECTED]
> > --------------------------------------------------------------------
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
> On assignment for IBM at http://www.iCAIR.org
> Board Chairman, Internet Society http://www.isoc.org
>
> "We shall need a number of efficient librarian types
> to keep us in order." - Alan Turing, 1947.
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
