Re: [6tisch] T: FW: I-D Action: draft-satish-6tisch-6top-sf1-00.txt

["S.V.R.Anand" <[e-mail]>]

Hi Xavi,

Yes, I agree. For LLNs, I suppose we might need to adapt RSVP suitably. In
my mail I tried to weigh the options with RSVP in mind.

Anand


On Friday 10 June 2016 01:45 PM, Xavi Vilajosana Guillén wrote:
> 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 <[e-mail] 
> <mailto:[e-mail]>>:
>
>     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:[e-mail]] > Ñ öô:
>     2016t6 9å 20:19 > 6öº: Satish Anamalamudi (Satish Anamalamudi);
>     [e-mail] <mailto:[e-mail]> > ;˜: 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:[e-mail]] On
>     Behalf Of Satish Anamalamudi (Satish Anamalamudi) > Sent: 06 June
>     2016 15:31 > To: [e-mail] <mailto:[e-mail]> >
>     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:[e-mail]] On Behalf Of
>     >> [e-mail] <mailto:[e-mail]> >>
>     Sent: 2016t6 6å 17:54 >> To: [e-mail]
>     <mailto:[e-mail]> >> 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 >> [e-mail]
>     <mailto:[e-mail]> >>
>     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 > [e-mail] <mailto:[e-mail]> >
>     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 > [e-mail] <mailto:[e-mail]> >
>     https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>     _______________________________________________
>     6tisch mailing list
>     [e-mail] <mailto:[e-mail]>
>     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­
>
> [phone]| [e-mail] <mailto:[e-mail]>­ 
> | Skype­: xvilajosana
> http://xvilajosana.org <http://xvilajosana.org>
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> ­