forces protocol updates draft-ietf-forces-protocol-04.txt robert haas, [email protected] aug 1,...

ForCES protocol updatesdraft-ietf-forces-protocol-04.txt

Robert Haas, [email protected]

Aug 1, 2005

IETF 63, Paris

ForCES protocol updates. IETF 63. Robert Haas, [email protected] 2

Technical issues in the tracker

• http://www.mip4.org/issues/tracker/forces/

http://www.mip4.org/issues/tracker/forces/


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


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


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


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


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


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


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


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


Issue 28: LFB Instance Select

• Idea: need to address multiple instances simultaneously ?

• Discussion: Instance Select TLV proposed

• Status: Pending

• Proposal: ?


Issue 30: Event subscription

• Problem: should all events be subscrib-able ?

• Discussion: yes

• Status: closed


Issue 31: Notification Response Message

• Problem: Is a special “Notification Response” message needed ?

• Discussion: use the ACK flags in the common header

• Status: closed


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


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


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.


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


Issue 34: Header flags

• Problem: Definition of ACK, Priority, Throttle flags in the Common Header

• Discussion: TBD

• Status: Pending


Issue 36: FE/CE Failover

• Problem: Clarify FE/CE failover

• Discussion: TBD

• Status: Pending


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


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


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


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


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


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


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

forces protocol updates draft-ietf-forces-protocol-04.txt robert haas, [email protected] aug 1,...

Documents

teardownresult tlv

pl message

unspecified error

dataraw tlvs

administrator1 error

beat2 error

pl response messagesdiscussion

fe protocol lfbstatus