1. ForCES protocol updates draft-ietf-forces-protocol-04.txt Robert Haas, rha@zurich.ibm.com Aug 1, 2005 IETF 63, Paris

2. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com2 Technical issues in the tracker http://www.mip4.org/issues/tracker/forces/

3. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com3 Issue 6: Data encapsulation Idea: Two types of DATA TLV: DATARAW or PACKED-DATARAW. DATARAW contains ILVs for each element. Suitable when optional elements are encapsulated. Discussion: ILV with 32-bit Index and 32-bit Length –TBD debate on using ILV vs PATH Status: Accept

4. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com4 Issue 11: heartbeat piggy-backing Idea: skip heartbeats as long as there is protocol activity Should be controllable via a flag in the FE Protocol LFB Status: Accept

5. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com5 Issue 12: TML support for message obsolescing Idea: include support for letting the PL layer indicate to the TML if some messages queued for sending may be cancelled. Discussion: most transports do not support this Status: Reject

6. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com6 Issue 22: Response formatting Idea: provide various level of information via Result TLV in all PL response messages Discussion: –If successful, a GET-RESPONSE contains DATARAW TLVs, otherwise a RESULT TLV –SET-RESPONSE contain RESULT TLVs in place of the DATARAW TLVs of the SET message. –RESULT TLV: 0 = success 1 = no such object 2 = permission denied 3 = invalid value (the dataraw could not validly be stored in the field) 4 = invalid array creation (when the subscript in an array create is not allowed) 255 = unspecified error (for when the FE can not decide what went wrong) –If there are multiple fields set in a DATARAW, once causes an error, then the whole operation returns an error –If there are multiple field errors, the FE chooses which error to return. Status: pending Proposal: accept

7. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com7 Issue 23: Common Header issues Ideas: –Windowing at the PL layer –CE-FE master-slave relationship or peer-to-peer ? –Atomicity and batching flags in the PATH ? Discussion –No requirements to wait for PL ACKs before sending next PL message. –CE-FE are master-slave, replies and events notifs only go FE->CE –Flags belong to the Common Header Status: closed

8. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com8 Issue 24 (and 41): CE LFB Idea: use of a CE LFB to originate events sent from the CE to the FE (for instance) Discussion: no real need for this, remove it. Status: closed

9. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com9 Issue 25: Associations Problem: Leaving src ID to 0 when setting up the association (message from FE to CE) and using a dest mcast ID Discussion: does not pose any issue Status: closed

10. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com10 Issue 26: Teardown reason Problem: format of the association setup and teardown messages Discussion: use LFBSelect for Setup, and only a Teardown-Result TLV for Teardown: 0 - normal teardown by administrator 1 - error - loss of heart-beat 2 - error - out of bandwidth resource 3 - error - out of memory resource 4 - error - application crash.. 255 - error - other or unspecified Status: closed

11. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com11 Issue 28: LFB Instance Select Idea: need to address multiple instances simultaneously ? Discussion: Instance Select TLV proposed Status: Pending Proposal: ?

12. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com12 Issue 30: Event subscription Problem: should all events be subscrib-able ? Discussion: yes Status: closed

13. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com13 Issue 31: Notification Response Message Problem: Is a special “Notification Response” message needed ? Discussion: use the ACK flags in the common header Status: closed

14. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com14 Issue 32: Packet redirects Problem: LFB(s) and format of packet redirection Discussion: Move definition of Redirect LFB to another doc. Use a special TLV (no need of LFB- select TLV) for redirected packets. Include metadata (see next slides) –static metadata ID assignment, may require metadata transcoding Status: Pending

15. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com15 Message Body: Consists of one or more TLVs, with every TLV having the following data format: 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 = Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LFB class ID: There are only two possible LFB classes here, the 'RedirectSink' LFB or the 'RedirectSource' LFB[FE-MODEL]. 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 'RedirectSource'. Instance ID: Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Meta Data TLV: This is a TLV that specifies meta-data associated with followed redirected data. The TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = META-DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Meta Data ID is an identifier for the meta data, which is usually defined by FE-Model[FE-MODEL].

16. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com16 Usually there are two meta data that are necessary for CE-FE redirect operation. One is the redirected data type (e.g., IP packet, TCP packet, or UDP Packet). For an FE->CE redirect operation, redirected packet type meta data is usually a meta data specified by a Classifier LFB that filter out redirected packets from packet stream and sends the packets to Redirect Sink LFB. For an CE->FE redirect operation, the redirected packet type meta data is usually directly generated by CE. Another meta data that should be associated with redirected data is the port number in a redirect LFB. For a RedirectSink LFB, the port number meta data tells CE from which port in the lFB the redirected data come. For a RedriectSource LFB, via the meta data, CE tells FE which port in the LFB the redirected data should go out. Redirect Data TLV: This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REDIRECTDATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected Data |.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirected Data: This field presents the whole packet that is to be redirected. Obviously, the packet should be 32bits aligned.

17. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com17 Issue 33: Command Pipelining Idea: send multiple messages to the FE without waiting for the ACKS Discussion: Protocol FSM allows sending PL messages without waiting for previous ACKs. Correlators allow to match ACKs. Throttle bits ? Status: Pending

18. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com18 Issue 34: Header flags Problem: Definition of ACK, Priority, Throttle flags in the Common Header Discussion: TBD Status: Pending

19. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com19 Issue 36: FE/CE Failover Problem: Clarify FE/CE failover Discussion: TBD Status: Pending

20. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com20 Issue 37: FE Protocol LFB Problem: Definition of the attributes in the FE Protocol LFB Discussion: remove requirement for the FE Protocol LFB. But global default values MUST be assigned to parameters such as timer interval, etc. FE Protocol LFB described in a separate doc. default value for the heartbeat interval is 300 milliseconds. default value for the Association Expiry timer is 900 milliseconds, i.e. an association expires after 3 missing heartbeats. Status: closed

21. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com21 Issue 40: BLOCK operations Idea: Have block allocations Discussion: optimization that can be added later. Maybe a capability of the FE to advertise. Status: Pending Proposal: Reject

22. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com22 Issue 47: PL sequence number and correlator Problem: Clarify use of sequence number. Add a correlator field to be returned by the FE as is in its responses Discussion: sequence number now real sequence number. Add 32-bit correlator. Need to state how FE must treat the correlator. Status: Accepted

23. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com23 Issue 52: Association Setup Problem: allow FE to advertise unsolicited information in the Association Setup message. Allow the CE to set attributes in the Association Setup Response message. Discussion: May use GET-RESPONSE for unsolicited info, and SET. Status: Pending Proposal: Accept

24. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com24 Issue 55: Execution, recovery of transactions in intermediate state Problem: how to recover after association is lost and back ? What about transactions that were interrupted ? Discussion: Cannot assume what happens to the FE while it is unassociated, so the CE must reload all the FE state once the FE is associated again. Status: Pending Proposal: Reject

25. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com25 Issue 56: Association Setup Results Issue: define the error codes for the Association Setup Response: Discussion: An Association-Setup-Resp- TLV: 0 = success 1 = FE ID invalid 2 = too many associations 3 = permission denied Status: Pending

26. ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com26 Issue 57: Operation types Discussion: CONFIG message: Set (also for event subscription), delete (?), add (?), update (?), replace (?), del-all (?), cancel (?) CONFIGURATION-RESPONSE message: Same as above with *-response QUERY message: Get QUERY-RESPONSE message: Get-response EVENT-NOTIFICATION message: Report EVENT-NOTIFICATION-RESPONSE message: Report-response ASSOCIATION-SETUP message: Get-response (optional, used to advertise fields from the FE LFB and/or FE Protocol LFB in an unsolicited manner) ASSOCIATION-SETUP-RESPONSE message: Set (optional, only to set fields in the FE LFB and/or FE Protocol LFB) PACKET REDIR, HEARTBEAT do not have operations. Status: Pending