六合彩 » SlideShare
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

六合彩 » SlideShare

on

  • 1,044 views

后,我衣服好象就没干过,喉咙原本还算滋润,可后来一路上听到其香港六合彩人喝水的咕咚咕咚声响,我这嗓子就象冒了烟,跟武侠小说里不幸中了鹤顶红的...

后,我衣服好象就没干过,喉咙原本还算滋润,可后来一路上听到其香港六合彩人喝水的咕咚咕咚声响,我这嗓子就象冒了烟,跟武侠小说里不幸中了鹤顶红的巨毒一样,奇痒无比,痛苦不堪.
车厢里相当鼯燥,人挨着人,限载二十人的车厢被那个要钱不要命的老板活活塞了三十多人,香港六合彩这些有意见的也不敢提,毕竟香港六合彩只要命不敢要舒坦.
本来天气就热,加上皮肤粘着皮肤,大腿贴着大腿,就跟锅贴饺一样,也有黄锃锃的油光,显然那是汗渍.
刚开始我还是满喜欢这钟感觉的——我坐在最后一排,靠窗坐着一个十八、

Statistics

Views

Total Views
1,044
Views on SlideShare
1,044
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Marker (Protocol Data Unit) Aligned Framing, or MPA.

六合彩 » SlideShare Presentation Transcript

  • 1. MPA update (-00) ( Marker PDU Aligned Framing for TCP) draft-ietf-rddp-mpa-00 Paul R. Culley HP 11-11-2003
  • 2. Draft-ietf-rddp-mpa-00
    • Now a workgroup document slated as “informational RFC”
    • In 4 th revision
    • Few comments received
  • 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.
  • 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”.
  • 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…
  • 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).
  • 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.
  • 8. IWarp Startup sequence* Initiator 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” Responder 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 MPA Request Frame, Consumer binds MPA to DDP, MPA sends MPA Reply Frame, FPDU decoding enabled. MPA gets first FPDU; Goes into Full iWARP mode. First iWARP message sent by RNIC (When WQE is posted) * No private data interactions shown
  • 9. IWarp Startup sequence with TCP 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) Initiator TCP SYN sent 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” Responder 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 first FPDU; Goes into Full iWARP mode. First iWARP message sent by RNIC (When WQE is posted) TCP gets SYN Sends SYN-Ack TCP gets SYN-Ack Sends Ack Note Note: The Ack may be in the same segment as the MPA Request Frame in some implementations!
  • 10. MPA Request Frame
    • 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
    Key (“MPA ID Req Frame”) 16 bytes M 1b C 1b Res(0) 6b Rev (0) 8b PD_Length 16b Private Data “PD_Length” bytes
  • 11. MPA Response Frame
    • 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
    Key (“MPA ID Rep Frame”) 16 bytes M 1b C 1b Res(0) 6b Rev (0) 8b PD_Length 16b Private Data “PD_Length” bytes
  • 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)
  • 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.
  • 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
  • 15. End