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

[Xavi Vilajosana Guillén <[e-mail]>]

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]>:

> 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] <[e-mail]>] >
> Ñ öô: 2016t6 9å 20:19 > 6öº: Satish Anamalamudi (Satish Anamalamudi);
> [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]
> <[e-mail]>] On Behalf Of Satish Anamalamudi (Satish
> Anamalamudi) > Sent: 06 June 2016 15:31 > To: [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]
> <[e-mail]>] On Behalf Of >> [e-mail]
> >> Sent: 2016t6 6å 17:54 >> To: [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. >> >> Internet-Drafts are also available by anonymous FTP
> at: >> ftp://ftp.ietf.org/internet-drafts/ >> >>
> _______________________________________________ >> I-D-Announce mailing
> list >> [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] > 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] > https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [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]­ | 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)



­