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

Hi Robert,

see reply in line. 
thank you.
weiming
  ----- Original Message ----- 
  From: Robert Haas 
  To: Wang,Weiming 
  Cc: Khosravi, Hormuzd M ; ram.gopal@nokia.com ; avri@acm.org ; forces-protocol@ietf.org ; Jamal Hadi Salim ; Ligang Dong 
  Sent: Saturday, October 23, 2004 2:53 AM
  Subject: 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

 <?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]
  [W]done.

 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".
  [W]done.

<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.
  [W]My thought is which part of a packet will be redirected to will be decided by other LFBs than the specific redirect LFB. In this way, we leave much flexibility.

  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 ?
  [W] I think the most important to have a specific redirect message is for DoS prevention. I'v add some thing.
<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 !
  [W]My thought is different. If some LFBs that have data redirected to CE, they just use a redirect LFB as its output. In this way, we just save
  the work to configure the LFB for redirect functions.For instance, if we need to have some classifier to redirect something, we just need to have one output
  of the classifier connected to redirct LFB, rather than to define a specific attributes in the classifier for redirect. I even can not see how such attribute can be defined. 

<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 ?
  [W] sequening for redirect data is important. What I mentioned here is only the sequence inside one message(one UDP ), I see sequence number in message header is in charge of sequence between UDP packets. I suppose a loss of UDP will lead to retransmission controlled by PL. If we use TCP, the TML is in charge of this.

<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"
  [OK]

<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"
  [W]thanks.
  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 ?
  [W]I agree well. I thought of this, just thinking this Operation TLV is really a topic for much more discussion, therefore I leave it there. Anyway, let me try to change it. 

</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 ?
  [W]also agree well. hope Jamal will not object to it. I try to change it first.

</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.
  OK.
  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 ?
  [W] yes, it matters. actually I still have not defined the message format for CE events. I'm sure the definition should be different for the LFBs.
  If the CE-LFB thought can proceed more, it will help the definition here.

</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

------------------------------------------------------------------------------

  _______________________________________________
  Forces-protocol mailing list
  Forces-protocol@ietf.org
  https://www1.ietf.org/mailman/listinfo/forces-protocol