Re: Model: FE Attributes
"Wang,Weiming" <[email protected]>
| Newsgroups | gmane.ietf.forces |
|---|---|
| Message-ID | <003201c6f450$6894c8a0$b719fea9@WangHome> |
Considering that the protocol has to make some changes on something anyway, making the TML related attributes as FE protocol object may be a good choice. Jamal and other guys, could you give some thought? thanks, weiming ----- Original Message ----- From: "Weiming Wang" <[email protected]> > If we are religious about this, yes, I agree the attributes related to TML are more relavent to FE Protocol LFB, but we may not be too religious about this. > > I don't think it is a good way to set a specific TML LFB for this purspose. I'v already thought of this idea, but I was just drawn back by the odd appearance of the TML LFB if we deifine it. Thinking that it have to have an odd relationship with FE Protocol LFB, between them a receive and send channel have to exist, while it is out of scope of FE topology. > > Note that events on congestion state is triggered as an alert notification. I don't think transmission of such one notification will add to the congestion state. It can be sent with highest priority to make it not too late to report to CE. > > I object to report individual TML specific statistics to PL layer, which are too implementation oriented and seem not very useful. I think we'v discussed this before and had a rough consensus. > > thanks, > Weiming > > ----- Original Message ----- > From: "Joel M. Halpern" <[email protected]> > > > The obvious question is whether that belongs in the FE Object LFB, > > the FE Protocol Object LFB, or an additional TML LFB? I am inclined > > to think that at least some of it goes in one of the first two. > > > > The other question is whether some of that information will actually work. > > A ForCES Notification based on TML congestion is likely to increase > > congestion, and if it arrives at all it will arrive to late to be > > helpful. We probably do need the FE side TML statistics, and there > > may be some parameters for some TMLs. But those would presumably be > > in a TML LFB, since they may be specific to the TML. > > > > Yours, > > Joel > > > > At 10:54 PM 10/14/2006, Wang,Weiming wrote: > >>Hi Joel and Allen, > >> > >>The following text is about the xml description of the FE Object > >>attributes, capability, events that are related to TML management, > >>and are expected to incorparate in current FE Object definition. An > >>xml file is also included in the attachment. To better understand > >>the attributes, the latest tml service primitive draft revision > >>version is also attached, though it is not yet submitted due to some > >>last modification. > >> > >>thanks, > >>Weiming > >>---------- > >><?xml version="1.0" encoding="UTF-8"?> > >><!-- FE Object Attributes, events, and capabilities that relates to TML --> > >> > >><dataTypeDefs> > >> <dataTypeDef> > >> <name>TMLErrorType</name> > >> <struct> > >> <element elementID="1"> > >> <name>ErrorType</name> > >> <atomic> > >> <baseType>uint16</baseType> > >> <specialValues> > >> <specialValue value="1"> > >> <name>AllLocalTMLlinkFailed</name> > >> <synopsis> > >> All local TML links failed. > >> </synopsis> > >> </specialValue> > >> <specialValue value="2"> > >> <name>PartLocalTMLlinkFailed</name> > >> <synopsis> > >> Part of local TML links failed. > >> </synopsis> > >> </specialValue> > >> <specialValue value="3"> > >> <name>PeerTMLlinkUnavailable</name> > >> <synopsis> > >> Peer TML link unavailable > >> </synopsis> > >> </specialValue> > >> <specialValue value="4"> > >> <name>PeerTMLlinkLeft</name> > >> <synopsis> > >> Peer TML link abnormally left > >> </synopsis> > >> </specialValue> > >> </specialValues> > >> </atomic> > >> </element> > >> <element elementID="2"> > >> <name>ErrorStatus</name> > >> <atomic> > >> <baseType>uchar</baseType> > >> <specialValues> > >> <specialValue value="1"> > >> <name>ErrorHappened</name> > >> </specialValue> > >> <specialValue value="0"> > >> <name>ErrorReleased</name> > >> </specialValue> > >> </specialValues> > >> </atomic> > >> </element> > >> </struct> > >> </dataTypeDef> > >> <dataTypeDef> > >> <name>TMLCongestionAlertType</name> > >> <struct> > >> <element elementID="1"> > >> <name>AlertType</name> > >> <atomic> > >> <baseType>uint16</baseType> > >> <specialValues> > >> <specialValue value="1"> > >> <name>ControlCongestionAlert</name> > >> <synopsis> > >> Congestion alert from control channel > >> </synopsis> > >> </specialValue> > >> <specialValue value="2"> > >> <name>RedirectCongestionAlert</name> > >> <synopsis> > >> Congestion alert from redirect channel > >> </synopsis> > >> </specialValue> > >> <specialValue value="3"> > >> <name>DoSAlert</name> > >> <synopsis> > >> Alert of DoS attack from redirect data > >> </synopsis> > >> </specialValue> > >> </specialValues> > >> </atomic> > >> </element> > >> <element elementID="2"> > >> <name>AlertStatus</name> > >> <atomic> > >> <baseType>uchar</baseType> > >> <specialValues> > >> <specialValue value="1"> > >> <name>AlertHappened</name> > >> </specialValue> > >> <specialValue value="0"> > >> <name>AlertReleased</name> > >> </specialValue> > >> </specialValues> > >> </atomic> > >> </element> > >> </struct> > >> </dataTypeDef> > >> <dataTypeDef> > >> <name>TMLType</name> > >> <synopsis> > >> Transportation Mapping Layer(TML) media type > >> </synopsis> > >> <atomic> > >> <baseType>uint16</baseType> > >> <specialValues> > >> <specialValue/> > >> </specialValues> > >> </atomic> > >> </dataTypeDef> > >></dataTypeDefs> > >> > >><attributes> > >> <attribute access="read-only" elementID="10"> > >> <name>TMLError</name> > >> <synopsis> > >> The attribute records latest error report from TML > >> </synopsis> > >> <typeRef>TMLErrorType</typeRef> > >> </attribute> > >> <attribute access="read-only" elementID="11"> > >> <name>TMLCongestionAlert</name> > >> <synopsis> > >> The attribute records latest congestion alert from TML > >> </synopsis> > >> <typeRef>TMLCongestionAlertType</typeRef> > >> </attribute> > >> <attribute access="read-write" elementID="12"> > >> <name>WorkingTMLType</name> > >> <synopsis> > >> > >> </synopsis> > >> <typeRef>TMLType</typeRef> > >> <optional/> > >> </attribute> > >></attributes> > >> > >><capabilities> > >> <capability elementID="15"> > >> <name>SupportedTMLType</name> > >> <synopsis> > >> Supported TML media types for this TML > >> </synopsis> > >> <array type="variable-size"> > >> <typeRef>TMLType</typeRef> > >> </array> > >> <optional/> > >> </capability> > >></capabilities> > >> > >><events baseID="10"> > >> <event eventID="1"> > >> <name>TMLErrorReport</name> > >> <synopsis> > >> The FE TML error report to CE > >> </synopsis> > >> <eventTarget> > >> <eventField>TMLError</eventField> > >> </eventTarget> > >> <eventChanged/> > >> <eventReports> > >> <eventReport> > >> <eventField>TMLError</eventField> > >> </eventReport> > >> </eventReports> > >> </event> > >> <event eventID="2"> > >> <name>TMLCongestionAlert</name> > >> <synopsis> > >> Alert of TML Congestion in the FE > >> </synopsis> > >> <eventTarget> > >> <eventField>TMLCongestionAlert</eventField> > >> </eventTarget> > >> <eventChanged/> > >> <eventReports> > >> <eventReport> > >> <eventField>TMLCongestionAlert</eventField> > >> </eventReport> > >> </eventReports> > >> </event> > >></events> > >>------------------------ > >> > >>----- Original Message ----- > >>From: "Wang,Weiming" <[email protected]> > >> > Joel, > >> > > >> > The submission deadline is October 23, Monday, I > >> suppose? Because the model draft is inactive right now, so, if it > >> can not comply with this deadline and must be with Oct 16 as an > >> initial draft deadline, I suppose to go with the first way, or, we > >> may directly go with one submission. I can promise to finish my input by 15th. > >> > > >> > thanks, > >> > weiming > >> > > >> > > >> > ----- Original Message ----- > >> > From: "Joel M. Halpern" <[email protected]> > >> > > >> > > Any input will be appreciated. > >> > > I was hoping to get this in to the I-D editor before the flood for > >> > > the deadline, but that may not happen. > >> > > > >> > > There are a couple of ways forward. > >> > > If we get the draft revised without the FE Object information, we can > >> > > submit that, and then submit a revision with the information as soon > >> > > as you make it available to us. > >> > > If there are a number of other items where we find that folks are > >> > > promising updates, we can hold off submitting the draft until > >> we get those. > >> > > > >> > > Yours, > >> > > Joel M. Halpern > >> > > > >> > > At 11:10 AM 9/28/2006, Wang,Weiming wrote: > >> > > >Joel, > >> > > > > >> > > >I'm very sorry that I defered inputing something for the FE object > >> > > >as I propsed months ago, owing to the ugly busy business for the > >> > > >university which may have to be ttill Oct. 1st. > >> > > >I have to make the TML SP update first ( which I'm doing) before > >> > > >making things for the FE object, for things I'm to input is tied to > >> > > >the SP in some way, as we discussed . Could give me another one or > >> > > >two weeks for this? > >> > > > > >> > > >While at the same time, I also urge other guys to have more inputs > >> > > >for the FE object attributes. > >> > > > > >> > > >thanks > >> > > >weiming > >> > > > > >> > > >----- Original Message ----- > >> > > >From: "Joel M. Halpern" <[email protected]> > >> > > > > >> > > > > I am resending this note to the Forces list. > >> > > > > Folks, the FE Object is insufficient. > >> > > > > I am quite sure that it needs more information. > >> > > > > But without input I can not fix it. > >> > > > > I can pretend it is correct. > >> > > > > Likely, no reviewer will stop us publishing as is. > >> > > > > > >> > > > > Please! > >> > > > > > >> > > > > Section 5.3 notes that the FE Attributes in the FE Object is woefully > >> > > > > incomplete. > >> > > > > I believe this to be true. > >> > > > > However, without input I can not repair this. > >> > > > > > >> > > > > In the absence of text I will remove the note and we will simply be > >> > > > > insufficient. > >> > > > > > >> > > > > Yours, > >> > > > > Joel M. Halpern > >> > > > >>