Post on 17-Jan-2016
ForCES protocol updatesdraft-ietf-forces-protocol-04.txt
Robert Haas, rha@zurich.ibm.com
Aug 1, 2005
IETF 63, Paris
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 2
Technical issues in the tracker
• http://www.mip4.org/issues/tracker/forces/
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 11
Issue 28: LFB Instance Select
• Idea: need to address multiple instances simultaneously ?
• Discussion: Instance Select TLV proposed
• Status: Pending
• Proposal: ?
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 12
Issue 30: Event subscription
• Problem: should all events be subscrib-able ?
• Discussion: yes
• Status: closed
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 15
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].
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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.
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 18
Issue 34: Header flags
• Problem: Definition of ACK, Priority, Throttle flags in the Common Header
• Discussion: TBD
• Status: Pending
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 19
Issue 36: FE/CE Failover
• Problem: Clarify FE/CE failover
• Discussion: TBD
• Status: Pending
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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
ForCES protocol updates. IETF 63. Robert Haas, rha@zurich.ibm.com 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 *-responseQUERY message:
GetQUERY-RESPONSE message:
Get-responseEVENT-NOTIFICATION message:
ReportEVENT-NOTIFICATION-RESPONSE message:
Report-responseASSOCIATION-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