Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt

Weiming,
I have a few suggestions for your sections. See inline. Please review 
them and indicate to Avri if she should incorporate these into the final 
draft. It would be good if Avri could do the english-check on these 
sections to as I am not a native english speaker neither
Regards,
-Robert

Wang,Weiming wrote:

>Hi Avri,
>
>I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the
>attachments. It's a pity that I just find I can not pass to parse the file by
>xml2rfc because it included some of the format defined by you, therefore it
>seems I can not verify the correctness of the  file for the xml format. I really
>want to save some of your work but it seems I'm not able to. If you like, next
>time I would just use txt like Hormuzd did.
>
>There is no change to the definition part.
>
>Hormuzd, I have mostly tried best to follow your format, but still there are
>some places that I prefer my style. Anyway, it matters less.
>
>thank you.
>Weiming
>----- Original Message -----
>From: <avri@acm.org>
>  
>
>>On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote:
>>
>>    
>>
>>>I sent you the entire section so you can just put it in. You don't have
>>>to find any diffs. I have attached it again for your convenience.
>>>      
>>>
>>doesn't quite work like that.
>>but i have put in the changes as far as i can tell. check to make sure
>>i got it right.
>>
>>http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt
>>
>>    
>>
>>>BTW, where are you at this moment? in the US or Europe? Just curious in
>>>case we need to setup some conference calls.
>>>      
>>>
>>this week in the us - east coast.
>>
>>a.
>>
>>    
>>
>
>
>  
>
><?xml version="1.0" encoding="UTF-8"?>
><!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
>     *** RedirectMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>     *** RedirectMsgV1.1, 2004-06-18.
>-->
>
><section anchor="RedirectMsg" title="Packet Redirect Message">
>
><t>Packet redirect message is used to transfer data packets 
>    between CE and FE. Usually these data packets are IP packets, 
>    though they may sometimes associated with some metadata 
>    generated by other LFBs in the model, or they may 
>    occasionally be other protocol packets, which usually happen 
>    when CE and FE are jointly implementing some high-touch 
>    operations. Packets redirected from FE to CE are the data 
>    packets that come from forwarding plane, and usually are the 
>    data packets that need high-touch operations in CE.
>
 ... or packets for which the IP destination address is the NE. [Note 
that I distinguish high-touch operations from endpoint protocol processing]

> Packets 
>    redirected from CE to FE are the data packets that are 
>    generated by CE and are decided by CE to put into forwarding 
>    plane in FE.</t>
>
>  
>
don't write "generated by the CE". Such packets could very well be 
packets that initially were redirected from an FE. Instead, just say 
"come from the CE".

><t>By properly configuring related LFBs in FE, a packet can also 
>    be mirrored to CE instead of purely redirected to CE, i.e., 
>    the packet is duplicated and one is redirected to CE and the 
>    other continues its way in the LFB topology. </t>
>
>  
>
Side note: we will have to define how the packet header only can be 
passed to the CE, and leave the payload in the FE, until the CE decides 
what to do with the packet.

Second side note: we need to specify why we consider that 
packet_redirect deserves its own message type, and not simply be treated 
as an event fired by the Redirect LFB that contains, as part of the 
event data, the packet itself. My thinking is that using a specific 
message type is important to let the CE distinguish promptly if the 
message is an FE-internal event or an external packet that was just 
forwarded. Something like this should be written in the intro of this 
section. Weiming ?

><vspace blankLines="1" />
><list style="hanging" hangIndent="17">
><t hangText = "Editorial Note: "> 
>There are also discussions on how LFBs in FE model that are 
>    related to packet redirect operations should be defined. Although 
>    it is out of the scope of forces protocol, how to define the LFBs 
>    affect the Packet Redirect Message described here. Because currently
>    it is still in progress in FE model on how to define such LFBs, 
>    we try to post some thoughts on this here for discussion. They 
>    will be removed later along with the progress of the FE model work.
></t>
><vspace blankLines="1" />
><t hangText ="     Thought 1: ">
>To define LFBs called 'RedirectSink' and 'RedirectTap' for
>packet redirect.</t>
><t>An LFB in FE called 'RedirectSink' is responsible to collect 
>    data packets that need to be redirected to CE. From the 
>    perspective of the FE LFB topology, the 'RedirectSink' LFB 
>    is an LFB with only one input port and without any output 
>    port, and the input port can then be connected to any other 
>    LFB in FE model by means of a datapath in the forwarding 
>    plane. From the perspective of the ForCES protocol layer, 
>    the 'RedirectSink' LFB will generate the Packet Redirect 
>    Messages when it receives data packets from forwarding plane.
></t>
><vspace blankLines="1" />
><t>An LFB in FE called 'RedirectTap' is responsible to receive 
>    data packets that are redirected from CE. From the perspective 
>    of the FE LFB topology, the 'RedirectTap' LFB is an LFB with 
>    only one output port and without any input port, and the 
>    output port can then be connected to any other LFB in FE 
>    model by means of a datapath in the forwarding plane. From 
>    the perspective of ForCES protocol layer, the 'RedirectTap' 
>    LFB can receive the Packet Redirect Messages from CE, and 
>    un-encapsulate the data packets from the message and put 
>    them to datapaths in the forwarding plane. Actually the 
>    'RecirectTap' LFB acts more like a transcoder that transfers 
>    the ForCES protocol messages to normal data packets in IP 
>    forwarding plane. As a result, if we need to have redirected 
>    packets connected to some LFB (say a Scheduler) in FE model, 
>    we only need to connect the 'RedirectTap LFB to the Scheduler 
>    LFB directly via a datapath as follows:
><vspace blankLines="1" />
><figure anchor="LFB_Redirect"><artwork>
>                          +-----------------+       +-----------+
>                          | RedirectTap LFB |------>|           |
>                          +-----------------+       |           |
>                                                    | Scheduler |
>                              From other LFB   ---->|    LFB    |
>                                                    |           |
>                                                    +-----------+
></artwork></figure>
></t>
><vspace blankLines="1" />
><t>By use of several 'RedirectSink' LFBs and several 'RedirectTap' 
>    LFBs that connect to several different datapaths in FE 
>    forwarding plane, multiple packet redirect paths between 
>    CE and FE can be constructed. </t>
><vspace blankLines="1" />
><t hangText ="     Thought 2: ">
>    There might be another way a packet could be redirected:
>    directly by a forwarding path, e.g., by FPGA/ASIC/NP microcode. In 
>    such a case we do not need to put in a lot of smartness. Probably 
>    a link layer or even network level header is enough. The receiver 
>    demuxes it only based on some protocol type in the link layer or 
>    network transport layer. The pros for this appraoch is it may 
>    provide a fast and cost-effective path for packet redirect. The 
>    cons for this is it may more or less confuses the Fp reference 
>    point definition in ForCES framework. 
></t>
></list>
><vspace blankLines="1" />
><t>We describe the Packet Redirect Message data format in details 
>    as follows:</t>
><list style="hanging" hangIndent="1">
><t hangText= "Message Direction:  "><vspace />
>CE to FE or FE to CE
></t>
>
>
><t hangText= "Message Header:  "><vspace />
>The Message Type in the header is set to 
>    MessageType= 'PacketRedirect'. The ACK flags in the header 
>    SHOULD be set 'NoACK', meaning no response is expected by this 
>    message. If the ACK flag is set other values, the 
>    meanings will be ignored.
></t>
>
>
><t hangText= "Message Body: "><vspace />
>Consists of one or more TLVs, with every TLV having the 
>    following data format:
></t>
>
>  
>
><figure anchor="tlv_Redirect_Data">
><artwork>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Type = LFBselect       |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          LFB Class ID                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        LFB Instance ID                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ~                           ...                                 ~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
></artwork></figure>
>
><t hangText= "LFB class ID: "><vspace />
>There are only two possible LFB classes here, the 
>    'RedirectSink' LFB or the 'RedirectTap' LFB. If the message is 
>    from FE to CE, the LFB class should be 'RedirectSink'. If the 
>    message is from CE to FE, the LFB class should be 'RedirectTap'.
></t>
>
>  
>
Why restrict this ? If any other LFB wants to generate a packet redirect 
to the CE, let him do it !

><t hangText= "Instance ID: "><vspace />
>Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB.
></t>
>
>
><t hangText= "Operation TLV: "><vspace />
>This is a TLV describing one packet of data to be directed 
>    via the specified LFB above. The order of the data number is 
>    also the order the data packet arrives the redirector LFB, that 
>    is, the Redirected Data #1 should arrive earlier than the 
>    Redirected Data #2 in this redirector LFB. The TLV format is 
>    as follows:
></t>
>  
>
If what you mean is sequencing the redirected packet then I think it is 
dangerous. Assume you use UDP to transport the redirected packets from 
the CE to the FE. If one is lost, then what will the FE do with the next 
ones ?

>
><figure anchor="tlv_Redirected_Data"><artwork>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (PAYLOAD)|               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Path(or Sequence Number?)              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ~                        Redirected Data                        ~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
></artwork></figure>
><t hangText= "Path(or Sequence Number?): "><vspace />
>[Under discussion and TBD]
></t>
><t hangText= "Type: "><vspace />
>[TBD]
></t>
>
><t hangText= "Redirected Data: "><vspace />
>This field will make a detailed description of the data to 
>    be redirected as well as the data itself. The encoding of the 
>    description is based on the ForCES FE model if the redirector 
>    LFB is defined by FE model, or based on vendor specifications 
>    if the redirector LFB is defined by vendors. The description 
>    will usually include the name (or the name ID) of the redirected 
>    packet data (such as 'IPv4 Packet', 'IPv6 Packet'), and the 
>    packet data itself. It may also include some metadata (metadata 
>    name (or name ID) and its value)associated with the redirected 
>    data packet.
></t>
></list>
></section>
>
><!-- $Log: RedirectMsg.xml,v $
><!-- Rewritten by Weiming Wang 2004/10/22
><!-- Incorparate LFBselect and Operation TLV 
><!--
><!-- Revision 1.7  2004/07/19 09:37:05  avri
><!-- Version 2 checkin
><!--
><!-- Revision 1.6  2004/06/23 05:05:34  avri
><!-- final edit for 00
><!--
><!-- Revision 1.5  2004/06/22 07:02:37  avri
><!-- remove
><!--
><!-- Revision 1.4  2004/06/22 07:01:00  avri
><!-- Team Edit from 00-7
><!--
><!-- Revision 1.2  2004-06-21 21:40:41+08  administrator
><!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
><!--
><!-- Revision 1.1  2004-06-21 21:09:41+08  administrator
><!-- Revision handed from Avri. - Weiming
><!--
><!-- Revision 1.3  2004/06/19 13:11:12  avri
><!-- Linefeeds
><!--
><!-- Revision 1.2  2004/06/19 13:05:00  avri
><!-- anchors
><!--
><!-- Revision 1.1  2004/06/17 03:45:55  avri
><!-- Initial revision
><!-- 
>     edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
>     *** RedirectMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>-->
>  
>
><?xml version="1.0" encoding="UTF-8"?>
><!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
>     *** QueryMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>     *** QueryMsgV1.1, 2004-06-18
>     - change EncodingType to Type
>     *** QueryMsgV1.2, 2004-10-20
>     - for ietf-protocol-01
>-->
>
><section anchor="QueryMsg" title="Query and Response Messages">
>  
>
Be more specific: "Query and Query Response Messages"

><t>The ForCES query and response messages are used for one ForCES 
>    element (CE or FE) to query other ForCES element(s) for various 
>    kinds of information. Current version of ForCES protocol limits 
>    the use of the messages only for CE to query information of FE. 
></t>
><section anchor="Query" title="Query Message">
>
><t>As usual, a query message is composed of a common header and 
>    a message body that consists of one or more TLV data format. 
>    Detailed description of the message is as below.</t>
><list style="hanging" hangIndent="4"> <vspace />
><vspace blankLines="1" />
><t hangText= "Message transfer direction:"> <vspace />
>Current version limits the query message transfer direction 
>    only from CE to FE.</t>
>
><t hangText= "Message Header:"> <vspace />
>The Message Type in the header is set to MessageType= 'Query'. 
>    The ACK flag in the header SHOULD be set 'ACKAll', meaning a 
>    full response for a query message is always expected. If the 
>    ACK flag is set other values, the meaning of the 
>    flag will then be ignored, and a full response will still be 
>    returned by message receiver.</t>
>
>
><t hangText = "Message body: "><vspace />
>The query message body consists of (at least) one or more than 
>    one TLVs that describe entries to be queried. The TLV is called 
>    LFBselect TLV and the data format is as below:
></t>
><figure anchor="msg_Query">
><artwork>
> 
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Type = LFBselect       |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          LFB Class ID                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        LFB Instance ID                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ~                           ...                                 ~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>
Typo in all figures: correct "Operatioin TLV"

General comment: in many cases the same type in TLV is used in different 
PL messages (Query vs Response, etc) and then the V is different. This 
WILL be a big source of implementation bugs. I think we should defined 
operation TLVs differently: GET and GET-RESP, SET and SET-RESP, REPORT 
and REPORT-RESP.
What do you think ?

>     
></artwork>
></figure>
><vspace blankLines="1" />
><list style= "hanging" hangIndent="17" >
><t hangText = "Editorial Note: ">
></t>
><list style="numbers" hangIndent="3">
><t>Under discussion is whether there is a need for explicit multiple LFB insatance
>    addressing here. One way to realize it is to define a specific Instance select
>    TLV to substitute above 'LFB Instance ID' field. The TLV may have following format:</t>
><figure><artwork>
>        INSselectTLV := Type Length Value
>        Type := INSselect
>        Value := InstanceID (RangeMark | Instance ID)+
>
></artwork></figure>
><t>An applicable RangeMark is '0xffffffff', the value of which is the same as 
>    Instance broadcast ID. Because there will be no broadcast address applied
>    in this place, there will be no worry of ambiguity here.</t>
></list>   
></list>
><vspace blankLines="1" />
><t hangText= "Operation TLV"><vspace />
>The Operation TLV for the 'Query' message is formatted as:
></t>
><figure anchor="tlv_Query">
><artwork>    
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (GET)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Path(or Attribute ID?)                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                            Query Data                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>  
>
Again, in all your sections, could you change "Type = Operations (GET)" 
to "Type = GET" and so on ?

></artwork></figure>
><t hangText= "Path(or Attribute ID?): "><vspace />
>[Under discussion and TBD]
></t>
>
><vspace blankLines = "1" />
><list style="hanging" hangIndent="17">
><t hangText = "Editorial Note:"> 
>There is a debate on whether we should use a 'Path' or simply an 'Attribute ID' 
>    or a 'Table ID' here at the protocol layer. A Path is used for data 
>    indexing for a table, while an 'Attribute ID' or a 'Table ID' only specify 
>    which attribute or table to use, leaving table index to be included in followed 
>    data.
></t>
></list>
><vspace blankLines="1" />
><t hangText= "Query Data: "><vspace />
>    [Under discussion and TBD]
></t>
></list>
><t>To better understand the above PDU format, we can show a tree structure for the 
>    format as below:
><figure>
>main hdr (type = Query)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = target LFB class
>     |        |
>     |        |
>     |        +-- LFBInstance = target LFB instance 
>     |        |
>     |        |
>     |        +-- T = operation { GET }
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        |        // under discussion
>     |        +-- T = operation { GET }
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        | 
>
></figure>
></section>
>
><section anchor="QueryResponse" title="Query Response Message">
><t>When receiving a query message, the receiver should process the 
>    message and come up with a query result. The receiver sends the 
>    query result back to the message sender by use of the Query 
>    Response Message. The query result can be the information 
>    being queried if the query operation is successful, or can also 
>    be error codes if the query operation fails, indicating the 
>    reasons for the failure.</t>
>
><t>A query response message is also composed of a common header and 
>    a message body consists of one or more TLVs describing the query 
>    result. Detailed description of the message is as below.</t>
><vspace blankLines="1" />
><list style= "hanging" hangIndent="4">
><t hangText= "Message transfer direction: "><vspace />
>Current version limits the query response message transfer direction 
>    only from FE to CE.
></t>
>    
><t hangText= "Message Header:  "><vspace />
>The Message Type in the header is set to MessageType= 'QueryResponse'. 
>    The ACK flag in the header SHOULD be set 'NoACK', meaning no further 
>    response for a query response message is expected. If the ACK flag is 
>    set other values, the meaning of the flag will then be 
>    ignored. The Sequence Number in the header SHOULD keep the same as 
>    that of the query message to be responded, so that the query message 
>    sender can keep track of the responses. 
></t>
>    
><t hangText= "Message body: "><vspace />
>The message body for a query response message consists of (at least) 
>    one or more than one TLVs that describe query results for individual 
>    queried entries. The TLV is also called LFBselect TLV, and has exactly 
>    the same data format as query message, except the Operation TLV inside
>    the TLV comprises the 'Query Response Data', instead of the 'Query Data',
>    as below:
></t>
>
><figure anchor="msg_Query_Response">
><artwork>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (GET)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Path(or Attribute ID?)                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Query Response Data                    |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
></artwork>
></figure>
>  
>
You should specify here that the order of the TLV in the Query-Reponse 
matches the TLVs in the Query. So there is always the same number of 
TLVs in the response as in the query.

Side note: we have not yet resolved the use of a transaction or sequence 
number that will be used for each PL message.

> 
><t hangText= "Query Response Data: "><vspace />
>[Under discussion and TBD]
></t>
></list>
>    
></section>
></section>
>
><!-- $Log: QueryMsg.xml,v $
><!-- Rewritten by Weiming Wang 2004/10/22
><!-- Incorparate LFBselect and Operation TLV 
><!--
><!-- Revision 1.10  2004/10/20 14:49:36  avri
><!-- Changes for draft-ietf-forces-protocol-00
><!--
><!-- Revision 1.9  2004/07/19 09:37:22  avri
><!-- Version 2 checkin
><!--
><!-- Revision 1.8  2004/06/23 05:05:47  avri
><!-- final edits for 00
><!--
><!-- Revision 1.7  2004/06/22 06:54:17  avri
><!-- Remove
><!--
><!-- Revision 1.6  2004/06/22 06:52:33  avri
><!-- Incorporate WW changes
><!-- Include team edits on 00-7
><!--
><!-- Revision 1.2  2004-06-21 21:40:25+08  administrator
><!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
><!--
><!-- Revision 1.1  2004-06-21 20:36:40+08  administrator
><!-- revision handed from Avri
><!--
><!-- Revision 1.5  2004/06/19 13:12:33  avri
><!-- formatting
><!--
><!-- Revision 1.4  2004/06/19 13:03:03  avri
><!-- fix cross reference
><!--
><!-- Revision 1.3  2004/06/19 12:21:11  avri
><!-- - change EncodingType to Type (from WW)
><!-- - fix formating
><!--
><!-- Revision 1.2  2004/06/17 03:43:47  avri
><!-- Replace with new WW files
><!--
>    edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong 
>     *** QueryMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>-->
>  
>
><?xml version="1.0" encoding="UTF-8"?>
><!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong 
>     *** EventMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>     *** EventMsgV1.1, 2004-06-18:
>     - change EncodingType to Type.
>-->
>
><section anchor="EventMsg" title="Event Notification and Response Messages">
>
><t>The Event Notification Message is used for one ForCES element 
>    to asynchronously notify one or more other ForCES elements 
>    in the same ForCES NE on just happened events in it. The 
>    Event Notification Response Message is used for the receiver 
>    of the Event Notification Message to acknowledge the reception 
>    of the event notification.</t>
>
><t>Events in current ForCES protocol can be categorized into following types:</t>
><t><list style="symbols">
><t>Events happened in CE</t>
><t>Events happened in FE</t>
>  
>
Why does this matter for the protocol ?

></list></t>
>
><t>Events can also be categorized into two classes according to 
>    whether they need subscription or not. An event in one ForCES 
>    element that needs to be subscribed will send notifications to 
>    other ForCES elements only when the other elements have subscribed 
>    to the element for the event notification. How to 
>    subscribe/unsubscribe for an event is described in the Configure 
>    Message in Section 6.3. An event that needs not to be subscribed 
>    will always send notifications to other ForCES elements when the 
>    event happens. An event definition made by ForCES protocol, ForCES 
>    FE model, or by vendors will state if the event needs subscription or not.</t>
><vspace blankLines="1" />
><list style="hanging" hangIndent="17" >
><t hangText="Editorial Note: " >
>There is an argument that it is preferable to have 
>all events subscribable.
></t>
></list>
>
>
><section title="Event Notification Message">
>
><t>As usual, an Event Notification Message is composed of a common 
>    header and a message body that consists of one or more TLV data 
>    format. Detailed description of the message is as below.</t>
><list style="hanging" hangIndent="1">
><t hangText= "Message Transfer Direction:  "><vspace />
>FE to CE, or CE to FE
></t>
>
>
><t hangText= "Message Header:  "><vspace />
>The Message Type in the message header is set to <vspace />
>    MessageType = 'EventNotification'. The ACK flag in the header 
>    can be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 
>    Note that the 'Success' here only means the receiver of the message 
>    has successfully received the message.
></t>
>
>
><t hangText= "Message Body: "><vspace />
>The message body for an event notification message consists 
>    of (at least) one or more than one TLVs that describe the 
>    notified events. The TLV is defined as follows:
><vspace blankLines="1" />
></t>
>
><figure anchor="tlv_Event_Notification">
><artwork>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Type = LFBselect       |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          LFB Class ID                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        LFB Instance ID                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ~                           ...                                 ~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Operatioin TLV                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
></artwork></figure>
>
><t hangText= "Operation TLV: "><vspace />
>This is a TLV that describes the event to be notified, as follows:
></t>
>
><figure anchor="tlv_Event"><artwork>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (REPORT) |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Path(or Event ID?)                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                            Event Data                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
></artwork></figure>
><t hangText= "Path(or Event ID): "><vspace />
>[Under discussion and TBD]
></t>
>
><t hangText= "Event Data: "><vspace />
>    [Under discussion and TBD]
></t>
></list>
><t>To better understand the above PDU format, we can show a tree structure for the 
>    format as below:
><figure>
>main hdr (type = Event Notification)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = target LFB class
>     |        |
>     |        |
>     |        +-- LFBInstance = target LFB instance 
>     |        |
>     |        |
>     |        +-- T = operation { REPORT }
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        |        // under discussion
>     |        +-- T = operation { REPORT }
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        | 
>
></figure>
></list>
></section>
>
><section title="Event Notification Response Message">
>
><t>After sending out an Event Notification Message, the sender may 
>    be interested in ensuring that the message has been received 
>    by receivers, especially when the sender thinks the event 
>    notification is vital for system management. An Event 
>    Notification Response Message is used for this purpose. The 
>    ACK flag in the Event Notification Message header are used to 
>    signal if such acknowledge is requested or not by the sender.</t> 
>
><t>Detailed description of the message is as below:</t>
><list style="hanging" hangIndent="1">
><t hangText= "Message Transfer Direction:  "><vspace />
>From FE to CE or from CE to FE, just inverse to the 
>    direction of the Event Notification Message that it responses.
></t>
>
>
><t hangText= "Message Header:  "><vspace />
>The Message Type in the header is set 
>    MessageType= 'EventNotificationResponse'. The ACK flag in the 
>    header SHOULD be set 'NoACK', meaning no further response for 
>    the message is expected. If the ACK flag is set other values, 
>    the meaning of the flag will then be ignored. 
>    The Sequence Number in the header SHOULD keep the same as that 
>    of the message to be responded, so that the event notificatin 
>    message sender can keep track of the responses.
></t>
>
><t hangText= "Message Body: "><vspace />
>The message body for an event notification message consists 
>  
>
correct above: event notification "response" message

>    of (at least) one or more than one TLVs that describe the 
>    notified events. The TLV is also called LFBselect TLV, and has exactly 
>    the same data format as Event Notification Message, except the Operation 
>    TLV inside the TLV comprises the event response data, instead of the 
>    'Event Data', as below:
>  
>
Again, you should mention that the each "Operation TLV" in the response 
corresponds one-to-one to a TLV in the notification.

><vspace blankLines="1" />
>
><figure anchor="tlv_Repsonse_Result">
><preamble>
>This contains a TLV that describe the response result 
>    as below:
></preamble>
><artwork>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (REPORT) |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Path(or Event ID?)                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Result     |   Reason      |         Code                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
></artwork></figure>
><t hangText= "Path(or Event ID?): "><vspace />
>[Under discussion and TBD]
></t>
><t hangText= "Result: "><vspace />
>This describes the reception result of the event notification 
>    message as below:
></t>
><figure><artwork>
>	Result Value             Meaning
>	'Success'       The event has been successfully received.
>	'Unsuccess'     The event has not been successfully received.
></artwork></figure>
>
><t hangText= "Reason, Code: "><vspace />
>This describes the reason and possible error code when 
>    the message is not successfully received. Note that only the 
>    failure at the protocol layer rather than the transport layer 
>    can be allocated here,
>
typo: not "allocated" but "handled".

> that is, if even the header part of the 
>    message to be responded can not be correctly received, the 
>    response to the message will not be able to be generated by 
>    the receiver.
></t>
><vspace blankLines="1" />
><list style="hanging" hangIndent="17">
><t hangText="Editorial Note: "> 
>There is a debate on whether the Event Notification 
>    Response Message is necessary or not. The pro for it is some event 
>    notification senders may be interested in knowing if receivers 
>    have had success/unsuccess receptions of the events or not. An 
>    alternative to generate such response is for the protocol to 
>    define a universal ACK message so that it can act as responses 
>    for any types of messages as well as the event notification 
>    messages, when the message senders are interested in knowing 
>    whether the messages have been successfully received or not 
>    (different from the responses for the message processing results).
></t> 
></list>
></list>
></section>
></section>
>
><!-- $Log: EventMsg.xml,v $
><!-- Rewritten by Weiming Wang 2004/10/22
><!-- Incorparate LFBselect and Operation TLV 
><!--
><!-- Revision 1.7  2004/07/19 09:38:16  avri
><!-- Version 2 checkin
><!--
><!-- Revision 1.6  2004/06/23 05:05:20  avri
><!-- final edit for 00
><!--
><!-- Revision 1.5  2004/06/22 06:59:23  avri
><!-- remove
><!--
><!-- Revision 1.4  2004/06/22 06:58:25  avri
><!-- Team edits from 00-7
><!--
><!-- Revision 1.2  2004-06-21 21:40:58+08  administrator
><!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
><!--
><!-- Revision 1.1  2004-06-21 21:07:54+08  administrator
><!-- Revision handed from Avri  - Weiming
><!--
><!-- Revision 1.3  2004/06/19 13:13:30  avri
><!-- Formatting
><!--
><!-- Revision 1.2  2004/06/19 12:29:52  avri
><!-- - change EncodingType to Type. (from WW)
><!-- Fice formatting
><!--
><!-- Revision 1.1  2004/06/17 03:45:02  avri
><!-- Initial revision
><!--
>     edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong
>     *** EventMsg V1.0, 2004-06-13, changes since last version:
>     - None, as the original version.
>-->
>  
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha