Subject: RE: [NSIS] IPv6 Flow Label

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 14 Jul 2002 14:48:43 +0100

Hi Sarantis,

[snip]
> 
> Yes, I was not clear.  What I meant was that NSIS would 
> define the flow
> specific treatment at the intermediate router to include 
> forwarding the
> packets of a flow to the same interface, i.e. to follow a 
> "path".  I am
> not sure if this can be an NSIS requirement or not (to always 
> direct flow
> specific traffic to the same interface if possible).
> 
> My understanding from reading the draft is that this responsibility
> is left to the "flow state management", i.e. NSIS in our case.
[reh] I don't believe that it is in the remit of NSIS (a signalling protocol group) to define router forwarding behaviour. In particular, my main concern is about intermediate routers which are not NSIS-aware in the first place. 

> 
> > > > 2) The draft seems to encourage (SHOULD) a highly granular 
> > > assignment of flow labels (e.g. section 4 rules 3 & 4). On 
> > > the other hand, there may be good reasons to use the same 
> > > label for a sequence of 'microflows' (e.g. successive files 
> > > in a bulk ftp transfer; the same point has been made on the 
> > > v6 list). Encouraging this granularity directly increases the 
> > > signalling burden. How strong is SHOULD?
> > > 
> > > I think, this is partially covered in Section 5, rule 1.  
> > >    
> > >        Depending on the method semantics, multiple such 
> triplets MAY
> > >        identify the same flow state (e.g. SCTP flows with multiple
> > >        addresses at either end-points, or a diffserv 
> > > classifier with an
> > >        address range.
> > > 
> > > This can be extended to cover the case for a "flowmask" in 
> > > which the first
> > > say 15 bits identify the flow state, while the last 5 identify the
> > > "microflow".
> > [reh] that's a very natural idea. on the other hand, it 
> can't be defined on a case by case basis, since that section 
> is about allowing multiple (including presently unknown) flow 
> state establishment methods to co-exist. if you think 
> co-existence is important, any such flowmask method would (I 
> think) need to be defined in this draft (which is probably overkill).
> > 
> > i don't think there's an easy answer to this question.
> 
> I think it can be defined on a case-by-case basis based on 
> specific NSIS
> signaling, i.e. an NSIS message defining the grouping of 
> several flowlabels
> into one logical flow.
> 
> By "flow state management methods" I thought something of 
> NSIS, RSVP, etc.
> In these cases, I don't see any interference between 
> different flow state
> management methods, if the flow label space of one is 
> independent from the
> flow label space of the other.  This is natural, since the application
> (or any other entity) initiating a flow (possibly of multiple 
> microflows)
> will choose to signal its requirements by only one signaling protocol.
> The flow labels will be unique for that source address, so 
> the flow state
> management at intermediate routers will not have to deal with 
> multiple flow
> state management methods dealing with the same flow.

[reh] the issue here is when the person managing the flow label space might not be the same person doing the signalling. The draft mentions one case (signalling initiated by flow receiver, penultimate paragraph of section 2), we are also interested in cases where the signalling could be initiated by intermediate nodes.

> 
> > > In that case the draft states that:
> > > 
> > >                           The flow state establishment method MUST
> > >         convey this classifying information to the IPv6 nodes 
> > > that need
> > >         to perform the classification.
> > > 
> > > i.e. this should be a NSIS requirement.
> > [reh] that is clear.
> 
> There is a conflict with draft-ietf-nsis-req-03.txt, section 
> 5.5.5 (possibly
> only naming conflict).  In the flow-label draft, several 
> microflows with
> different flow labels are treated as one flow, whereas in the 
> the nsis-req
> draft, the microflows are treated as independent flows (and their
> signaling is just grouped together for efficiency).
[reh] There are two points here:
1) Rule (1) of section 5 seems ambiguous: does the flow state establishment method have to convey the grouping of triplets, or just the state in each triplet. In other words, does 'this classifying information' refer to just the first sentence in the rule, or the second as well.
2) If it does refer to both, I don't believe the requirement is enforceable (after all, packets for different triplets might follow different paths, and the idea of the same state for each probably isn't even meaningful - which is why the NSIS requirement is restricted the way it is). If it doesn't, there is no conflict.

> Regards,
> -- Sarantis
Robert H.

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Sarantis Paskalis <[email-masked]>
Date: Mon, 15 Jul 2002 17:20:32 +0300

Hi Robert,

> [reh] I don't believe that it is in the remit of NSIS (a signalling protocol group) to define router forwarding behaviour. In particular, my main concern is about intermediate routers which are not…

I have no strong feelings about that.  I also agree that forwarding
behavior should be somewhat independent from the signaling protocol, ala
RSVP.

<snip>

> [reh] the issue here is when the person managing the flow label space might not be the same person doing the signalling. The draft mentions one case (signalling initiated by flow receiver, penultim…

The entity doing the signaling is responsible for the flow label(s)
classification.

In those cases, where the signaling is initiated by intermediate nodes,
flows can either be identified by some preconfigured templates or through
heuristics.  In either case, the intermediate node initiating the signaling 
is responsible for the flow grouping and the "flow classification" 
information forwarding.

> 2) If it does refer to both, I don't believe the requirement is enforceable (after all, packets for different triplets might follow different paths, and the idea of the same state for each probably…

My understanding is that it refers to both.  The argument about different
path for packets with different triplets could apply to packets of the
same triplet following different path (eg. due to load balancing).

I think there are two orthogonal management problems.  One is the flow
_state_ management in each node, i.e policy, QoS enforcement, etc.  The
other is the flow label space management.  The problem we are looking at
is the latter.  More specifically, I think we are looking at the
possibility of propagating the logical grouping of several microflows
that should be treated as one flow.  Something like RSVP Wildcard filter,
applied to flow labels.

The argument about possible different path for packets of different triplets 
equally applies to packets of the same triplet.  Packets with the same
triplet are not guaranteed to follow the same path (as mentioned before).
Actions for packets with the same flow label following a different path are
also enforceple for packets with different flow labels, but in the same
"flow" (as defined in draft-flow-label).

-- Sarantis

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