1 / 15

Marker PDU Aligned Framing for TCP: Update and Revision

Updates and revisions to MPA draft include changes in startup frames, addressing issues and minor comments for improved implementation. Document now slated as "informational RFC" after revision.

bfierro
Download Presentation

Marker PDU Aligned Framing for TCP: Update and Revision

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. MPA update (-00)(Marker PDU Aligned Framing for TCP) draft-ietf-rddp-mpa-00 Paul R. Culley HP 11-11-2003 MPA

  2. Draft-ietf-rddp-mpa-00 • Now a workgroup document slated as “informational RFC” • In 4th revision • Few comments received MPA

  3. Changes • Changed "Start Key" to two separate startup frames to facilitate identification of incorrect Active/Active startup. • Changed Active/Passive nomenclature to Initiator/Responder to reduce confusion with TCP startup and verbs doc (which used opposite sense). • Added "Private Data" to the startup key sequences. This also required describing the motivation and expected usage models along with some interface hints. Removed the "Private data“ stuff from appendix. • Added example "Immediate" startup with TCP and explanation. MPA

  4. Issues • One comment that Active/Active startup should be supported and it should be “easy”. • “All that is required is to define a third value for "instant start", which each side sends *and* expects to receive.” • This makes a “dual stack” implementation harder, because there is not a specific point where the legacy TCP stack can transition to the TCP/MPA/DDP stack. • Authors believe that not supporting this makes for easier implementations that avoid several difficult “races”. MPA

  5. Issues • One comment that MPA should be allowed to send FPDUs before startup frame is received. • Before you know how to set marker/CRC modes! • Argument that FPDUs with wrong settings can be dropped. • Don’t believe this should be allowed. • Adds unnecessary complexity to all receivers to deal with “incorrect” FPDUs without tearing down connection. • DDP Draft currently requires connection teardown. • Alternate is to allow mismatched settings to tear down connection… MPA

  6. Issues • One Comment that sending FPDUs should be allowed at least as soon as the “Start frame” is received at each end. • Currently the “Responder mode” endpoint is required to wait until the first FPDU is received. • This requirement was included to simplify “dual stack” implementations, in that the initiator could switch stacks without concern for an early FPDU (avoiding a race). MPA

  7. Minor Issues • One Comment indicated that we missed a “must”: MPA must pass any received private data to the ULP. • One Comment suggested that the difference between Initiator and Responder Startup frames should be more than one bit. • Comment that reference to “verbs” draft should be fixed or removed. • Comment that SCTP’s CRC reference is not correct. • Comment that difference between IPV4 and IPV6 headers should be noted when calculating FPDU lengths. MPA

  8. IWarp Startup sequence* Initiator Responder ULP says “Are you OK with going to iWARP?” in streaming mode This message is optional! ULP gets message;enables MPA in “Responder” mode and sends optional last streaming “Yes, I'm in iWARP now”, message. MPA waits for incoming <MPA Request Frame> ULP gets message; enables MPA in “Initiator” mode.MPA sends “MPA Request Frame” and waits for the “MPA Reply Frame” MPA gets MPA Request Frame, Consumer binds MPA to DDP, MPA sends MPA Reply Frame, FPDU decoding enabled. MPA gets MPA Reply Frame, Consumer binds MPA to DDP, MPA and DDP go into full operation.First iWARP message sent by RNIC(When WQE is posted) MPA gets first FPDU; Goes into Full iWARP mode. First iWARP message sent by RNIC (When WQE is posted) * No private data interactions shown MPA

  9. IWarp Startup sequence with TCP Initiator Responder TCP SYN sent TCP gets SYNSends SYN-Ack TCP gets SYN-AckSends Ack TCP to “Established”, Consumer enables MPA in responder mode, MPA waits for incoming <MPA Request Frame> As TCP enters “established”, Consumer enables MPA in “Initiator” mode.MPA sends “MPA Request Frame” with “private data” and waits for the “MPA Reply Frame” Note MPA gets MPA Request Frame, passes “private data” to consumer, Consumer binds MPA to DDP, MPA sends MPA Reply Frame, FPDU decoding enabled. MPA gets MPA Reply Frame, passes “private data” to consumer, Consumer binds MPA to DDP, MPA and DDP go into full operation.First iWARP message sent by RNIC(When WQE is posted) MPA gets first FPDU; Goes into Full iWARP mode. First iWARP message sent by RNIC (When WQE is posted) Note: The Ack may be in the same segment as the MPA Request Frame in some implementations! MPA

  10. MPA Request Frame Key (“MPA ID Req Frame”)16 bytes Key: The 16 char text string “MPA ID Req Frame” M: Marker bit (0=No marker, 1=Marker) C: CRC bit (0=No CRC desired, 1=CRC required) Rev: MPA revision (0 for this version) Res: Reserved, transmit as zero, not checked PD_Length: Length of any private data Private Data: ULP defined field M1b C1b Res(0)6b Rev (0)8b PD_Length16b Private Data“PD_Length” bytes MPA

  11. MPA Response Frame Key (“MPA ID Rep Frame”)16 bytes Key: The 16 char text string “MPA ID Rep Frame” M: Marker bit (0=No marker, 1=Marker) C: CRC bit (0=No CRC desired, 1=CRC required) Rev: MPA revision (0 for this version) Res: Reserved, transmit as zero, not checked PD_Length: Length of any private data Private Data: ULP defined field M1b C1b Res(0)6b Rev (0)8b PD_Length16b Private Data“PD_Length” bytes MPA

  12. Faq • Why must Initiator side wait for “MPA Reply Frame” before sending FPDU? • Ensures that BOTH ends are MPA/DDP endpoints before lots of data are sent. • only the “MPA Reply Frame” would be received by a non-MPA endpoint • MPA knows about marker and CRC modes • So first (few) FPDUs are not different (with Marker/CRC) MPA

  13. Faq • Why can’t Responder side send FPDUs as soon as “MPA Request Frame” is received? • Allows simpler “Initiator” side receiver design; “MPA Request Frame” and first FPDU cannot end up in same segment; allows time after Request frame arrives to reconfigure or switch stacks for FPDU reception. MPA

  14. Faq • How are Active/Active Peer to Peer connections dealt with? • If Peer to Peer connections are used, they MUST use some ULP mechanism to identify the MPA/DDP “Active” or “Passive” sides. • Can be based on Unique endpoint name, or • Can be some GUID in “private data”, or • Can be a full streaming negotiation MPA

  15. End MPA

More Related