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