Hello Satish and authors:
1)
It is not fully decided whether different global instances (RFC 6550) would use
different bundles. Maybe they should.
For tracks, we decided to use local instance, which means that the instance ID
is the combination of the source (or destination) and the instance ID in the
RPI.
Is this compatible with your work?
2)
These sentences back to back are hard to figure. Could you reword?
How exactly the end-to-end
resources are reserved is out-of-scope in this document.
How exactly the reserved resources are going to be scheduled for end-
to-end path of each instance with 6P protocol is defined with SF1.
3)
I the following text: should the intermediate node be allowed to add cells to
compensate for bad ETX?
Hence, the dynamic adoption (OTF) of cells should be
always triggered by the Source node. In other words, intermediate
nodes are not able to dynamically adapt(add/delete) the cells in an
ongoing instance
4)
Section “4.3. SF1 Allocation policy “ has an allocation policy that emulates
SF0. Why is that needed? I understand that for SF1, the updates are rare and
forced by the RSVP-TE protocol, aren’t they?
5)
I think the draft described the easy piece, which takes requests from a
resource reservation protocol and pushes them to 6P. I’m missing the more
difficult piece, the interaction with the RSVP protocol. Does the RSVP
propagation wait at each hop for the reservation at 6P layer to be complete? Is
there a 3p hase commit, like the actually booking comes with a return PATH
message? What are the error cases and roll back techniques?
Cheers,
Pascal
From: 6tisch [mailto:[email protected]] On Behalf Of Satish Anamalamudi
(Satish Anamalamudi)
Sent: vendredi 10 juin 2016 11:22
To: Xavi Vilajosana Guillén <[email protected]>; S.V.R.Anand
<[email protected]>
Cc: Lijo Thomas <[email protected]>; [email protected]
Subject: [6tisch] 答复: T: FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt
Hello Xavi,
alternately, we can take SDN approach whereby we can think of a virtual RSVP
protocol instance running in the PCE instead of on the motes. The PCE can
install the resources over CoAP messages. When track timeout is detected by the
PCE
via a network monitoring entity NME, it can take back the resources by sending
teardown message to the nodes. This way the resource reservation protocol
overhead has been
off-loaded to PCE.
With Regards,
Satish.
发件人: Xavi Vilajosana Guillén [mailto:[email protected]]
发送时间: 2016年6月10日 16:15
收件人: S.V.R.Anand
抄送: Satish Anamalamudi (Satish Anamalamudi); Lijo Thomas;
[email protected]<mailto:[email protected]>
主题: Re: [6tisch] T: FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt
Hi,
in protocols such as RSVP the tracks are maintained by refresh message and a
node timeout. Every time a refresh message is relayed through the track the
freshness counter is updated. If a track timeout is detected in a node the node
releases the resources. Nodes send periodic refreshing to maintain tracks in a
best effort way. Any node can sent at any time a tear down message to terminate
the track.
I think this idea can be extended and applied here.
regards,
Xavi
2016-06-09 20:35 GMT+02:00 S.V.R.Anand
<[email protected]<mailto:[email protected]>>:
Hi Lijo,
Your question on the lifetime of a TrackID can be split into two sub-questions.
One relates to the time itself, and the other is the track termination
procedure. A
short answer to the first is, it is application specific. The second is more
involved as there are several ways of terminating a track.
(i) One of the P2P end nodes can signal the PCE via a teardown message so that
PCE can release the chunks allocated to the intermediate nodes during the
resource reservation. The flip side of this seemingly graceful way is that if
there are plenty of short-lived tracks in the network, then the network will be
loaded with many control messages, not desirable in LLNs (ii) PCE automatically
reclaim the chunks based on the degree of idleness based on the information
obtained from NME. There is a trade-off here too.
Hope the above addresses your question.
Anand
On Thursday 09 June 2016 06:20 PM, Satish Anamalamudi (Satish Anamalamudi)
wrote:
> Hello Lijo, > > Thank you for your questions. > > Main role of TrackID : > 1.
> Track forwarding is very similar to IP forwarding where each and every hop is
> related to local Track-ID (like IP address) to switch the tracks towards
> Destination. Later, cells are used as implicit labels to switch it to
> next-hop cells of associated Track-ID. > 2. To identify the associated
> L2-bundles at each and every hop to forward the data to next-hop neighbors
> and dynamically adapt the cells in associated L2-bundles. > > As of now I
> don't have exact answer for "Life time of a TrackID". I will message to you
> very soon once I know the answer for it. > > With Regards, > Satish. >
> -----®öŸö----- > Ñöº: Lijo Thomas [mailto:[email protected]] > Ñ öô: 2016t6 9å
> 20:19 > 6öº: Satish Anamalamudi (Satish Anamalamudi);
> [email protected]<mailto:[email protected]> > ;˜: RE: [6tisch] FW: I-D Action:
> draft-satish-6tisch-6top-sf1-00.txt > > Hi Satish, > > I have a couple of
> queries regarding the SF1 draft . > > 1. In the draft it says a TrackID is
> generated for each 1 hop communication. > I had a feeling that the TrackID
> remains the same for an end-to-end packet flow. Please correct me if I am
> wrong > > 2. Life time of a TrackID > > Hope these are relevant to your draft
> : > > Thanks & Regards, > Lijo Thomas > > > -----Original Message----- >
> From: 6tisch [mailto:[email protected]] On Behalf Of Satish Anamalamudi
> (Satish Anamalamudi) > Sent: 06 June 2016 15:31 > To:
> [email protected]<mailto:[email protected]> > Subject: [6tisch] FW: I-D Action:
> draft-satish-6tisch-6top-sf1-00.txt > > Hello everyone, > > A new draft is
> proposed for hop-by-hop scheduling through Scheduling Function One(SF1). Your
> comments are highly appreciated. > > With Regards, > Satish. > >>
> -----Original Message----- >> From: I-D-Announce
> [mailto:[email protected]] On Behalf Of >>
> [email protected]<mailto:[email protected]> >> Sent: 2016t6 6å
> 17:54 >> To: [email protected]<mailto:[email protected]> >> Subject:
> I-D Action: draft-satish-6tisch-6top-sf1-00.txt >> >> >> A New Internet-Draft
> is available from the on-line Internet-Drafts >> directories. >> >> >>
> Title : Scheduling Function One (SF1) for hop-by-hop >> Scheduling
> in 6tisch Networks >> Authors : Satish Anamalamudi >>
> Mingui Zhang >> Charles E.
> Perkins >> S.V.R Anand >> Filename :
> draft-satish-6tisch-6top-sf1-00.txt >> Pages : 10 >> Date
> : 2016-06-06 >> >> Abstract: >> This document defines a 6top
> Scheduling Function called "Scheduling >> Function One" (SF1) to schedule
> end-to-end dedicated L2-bundles hop- >> by-hop for each instance. In
> addition, SF1 dynamically adapts the >> number of reserved cells in
> scheduled end-to-end L2-bundles of an >> ongoing instance through a
> Resource Reservation Protocol. SF1 uses >> the 6P signaling messages with
> a TrackID to add/delete cells in end- >> to-end L2-bundles of each
> instance. >> >> >> The IETF datatracker status page for this draft is: >>
> https://datatracker.ietf.org/doc/draft-satish-6tisch-6top-sf1/ >> >> There's
> also a htmlized version available at: >>
> https://tools.ietf.org/html/draft-satish-6tisch-6top-sf1-00 >> >> >> Please
> note that it may take a couple of minutes from the time of >> submission
> until the htmlized version and diff are available at >>
> tools.ietf.org<http://tools.ietf.org>. >> >> Internet-Drafts are also
> available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >>
> _______________________________________________ >> I-D-Announce mailing list
> >> [email protected]<mailto:[email protected]> >>
> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft
> directories: http://www.ietf.org/shadow.html or >>
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >
> _______________________________________________ > 6tisch mailing list >
> [email protected]<mailto:[email protected]> >
> https://www.ietf.org/mailman/listinfo/6tisch > > >
> -------------------------------------------------------------------------------------------------------------------------------
> > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook:
> https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is
> for the sole use of the intended recipient(s) and may contain confidential
> and privileged information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies and the original
> message. Any unauthorized review, use, disclosure, dissemination, forwarding,
> printing or copying of this email is strictly prohibited and appropriate
> legal action will be taken. >
> -------------------------------------------------------------------------------------------------------------------------------
> > > _______________________________________________ > 6tisch mailing list >
> [email protected]<mailto:[email protected]> >
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
--
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya
+34 646 633 681| [email protected]<mailto:[email protected]> | Skype:
xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)
[http://wine.rdi.uoc.edu/wp-content/uploads/2016/01/wine_LOGO_small2-e1453363995864.png]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
