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