1 / 26

ForCES protocol updates draft-ietf-forces-protocol-04.txt

ForCES protocol updates draft-ietf-forces-protocol-04.txt. Robert Haas, rha@zurich.ibm.com Aug 1, 2005 IETF 63, Paris. Technical issues in the tracker. http://www.mip4.org/issues/tracker/forces/. Issue 6: Data encapsulation.

daw
Download Presentation

ForCES protocol updates draft-ietf-forces-protocol-04.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Technical issues in the tracker • http://www.mip4.org/issues/tracker/forces/

  3. 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. 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. 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. 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. 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. 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. 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. 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. Issue 28: LFB Instance Select • Idea: need to address multiple instances simultaneously ? • Discussion: Instance Select TLV proposed • Status: Pending • Proposal: ?

  12. Issue 30: Event subscription • Problem: should all events be subscrib-able ? • Discussion: yes • Status: closed

  13. 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. 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. 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]. 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.

  16. 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. 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. Issue 34: Header flags • Problem: Definition of ACK, Priority, Throttle flags in the Common Header • Discussion: TBD • Status: Pending

  19. Issue 36: FE/CE Failover • Problem: Clarify FE/CE failover • Discussion: TBD • Status: Pending

  20. 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. 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. 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. 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. 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. 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. 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

More Related