31
SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee [email protected] University of New Hampshire InterOperability Lab - 1394 Consortium

SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee [email protected] University of New Hampshire InterOperability Lab -

Embed Size (px)

Citation preview

Page 1: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

SBP/2 over IEEE-1394and future 1394 specifications

Contact Info:

Christopher Lee

[email protected]

University of New Hampshire InterOperability Lab - 1394 Consortium

Page 2: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

2

What this presentation is…• A general technical overview of the Serial Bus Protocol 2• Questions that this presentation attempts to answer

– What is SBP/2?– Why is it needed? – What problems does it solve?– How does it work?– How is it implemented?

Page 3: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

3

What is SBP/2?

• The Serial Bus Protocol 2 was created by the T10 SCSI group. The group noticed the trend of the computer industry moving to faster, smaller, cheaper. Standard SCSI interfaces were bulky, expensive, and difficult to manage.

• Termination was a large problem, as was the “fat” cables used by SCSI technology.

Page 4: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

4

What is SBP/2? (cont)

• A parallel bus like SCSI is great for single peer to peer connections, but serial buses are better for peer to peer connections with multiple devices

• SBP/2 did not start originally for 1394, but modifications have made 1394 implementation anything but perfect

Page 5: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

5

Why SBP/2?

• 1394 needed a protocol for mass data storage. There are no defined command sets or protocols for 1394 so a generic data transfer command set was designed similar to SCSI.

• SBP/2 is to allow different devices to exchange data and commands between each other.

Page 6: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

6

Why SBP/2? (cont)

• SBP/2 can be used for: – hard drives, – magneto optical (MO) drives, – digital cameras, – CD-ROMs, – DVD-ROMs, – mass storage devices, – any device that can implement SCSI commands

Page 7: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

7

What problems does it solve?• Ability of devices to identify themselves without

prior knowledge

• To transfer data and commands abstractly, (encapsulated SCSI commands)

• Generic packet set of 1394 makes implementation of different protocols easier

• Enables devices to form large command task sets without transferring set beforehand

• Some security features via password login

Page 8: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

8

How does SBP/2 work?• Each capability of a node is designated with

a logical unit number (LUN)– nodes may have up to eight (8) LUNs

• The commands for the target are kept in system memory of the initiator– the target uses a read request block to fetch the

command (ORB)– the target uses a field in the ORB to determine

the direction of information flow

Page 9: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

9

Command Implementation

• All SBP/2 commands use the standard asynchronous packet transfers of read/write quadlet request/response, and read/write block request/response

Page 10: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

10

Initiators and targets...

• A transfer involves only one initiator, but can involve more than one target.

• All commands and data are encapsulated within a packet known as an operation request block (ORB)

Page 11: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

11

Address Pointers and Page Tables

– SBP/2 standard address pointer

» Last two bits not used, offset is higher

– When a data block is fragmented, a page table may be utilized

Page 12: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

12

ORBs• There are several different types of ORBs

– Management ORBs• responsible for administration commands, such as

login, logout, password management, and target lists

– Dummy ORB• blank ORBs used as a placeholder in a linked list

– Command Block ORB• actual command ORBs, encapsulated SCSI

commands

Page 13: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

13

ORBs (cont)

• All ORBs have the following fields in common– Notify bit

• advises the target whether or not completion notification is necessary

– rq_fmt field• specifies what type of ORB it is

Page 14: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

14

ORB Format

• Four ORBtype dependentfields

• Notify bit ->

• Last portionof field can -> vary in size

Page 15: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

15

ORB Linked Lists

• One of the features of SBP/2 is the ability for ORBs to be formed into a linked list– Each ORB has a field that gives the address of

the next ORB• A target may fetch several ORBs and depending

upon the node’s capabilities execute the commands in order or it may optimize the commands to make operation more efficient

Page 16: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

16

ORB Linked Lists

Page 17: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

17

Management ORBs

• Cannot be linked together

• Fields are function dependent• login

• query logins

• reconnect

• set password

• logout

• abort task

• target reset

Page 18: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

18

Management ORB Format

– Notify set to 1 ->

– Status block ->

Page 19: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

19

Dummy ORBs• Serve as placeholders in a command ORB

linked list– can be used to initialize a target fetch agent

Next_ORB pointer ->

Page 20: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

20

Command ORBs• Used to encapsulate data transfer or device

control commands

• All command ORBs have a next_ORB field– This field permits ORBs to be put in a linked list

• Contains a field indicating the size of the data block to be transferred

• Direction bit– Used to determine whether it needs to read or write

Page 21: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

21

Command Block ORB Format

Next_ORB pointer ->

Contains address of data buffer for command in -> command_block

Encapsulated SCSI command ->

Page 22: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

22

ORB Implementation• ORBs (commands) are stored on the initiator in

system memory

• Each node utilizes a doorbell register– The doorbell register is used to indicate to the target that

the initiator has added ORBs to a suspended linked list• any value written to the doorbell indicates the doorbell has been

“rung”

• Each node has a next_ORB register– An ORBs address is written to this register prior to

“ringing the doorbell”

Page 23: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

23

Login

• An initator must login to a target before using a node’s resources– A password verification must take place– Using a login procedure, addressing issues in a

dynamic environment are solved– Discovery of a node’s capabilities take place

during login

Page 24: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

24

Login ORB Format

» Password ->

» Address for response block ->

» Notify, reconnect, and LUN ->

» Password and response length ->

» Status block address ->

Page 25: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

25

Status Blocks• A login ORB specifies the address in

system memory that the target will use to store the status of command execution and/or completion

The status response is dependent on the command ->

Page 26: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

26

Passwords• Each node has a set of two passwords

– A master password • cannot be changed

• stored in static memory

• can only be read when already logged in

– Secondary password• can be changed

• should be noted on the end product

Page 27: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

27

Change Password Management ORB Format

• Changes secondary password– Uses login ID for verification

New password ->

Login_id of currently logged in initiator ->

Status block address ->

Page 28: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

28

Reconnect

• The login ORB specifies a reconnect time– If disconnected, the initiator attempts to

reconnect within the time-out period with a reconnect ORB

• The reconnect ORB specifies the address of a status block that the reconnecting target writes to

Page 29: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

29

Reconnect ORB Format

<- Login_id that node received from login process

^ Status block address ^

Page 30: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

30

Logout• When an initator no longer requires access

to a target’s resources, it shall signal a logout request

• Upon a successful logout, all resources are released

Status block address ->

Page 31: SBP/2 over IEEE-1394 and future 1394 specifications Contact Info: Christopher Lee chris.lee@unh.edu University of New Hampshire InterOperability Lab -

UNH InterOperability Lab - [email protected]

31

End Notes

• Current Microsoft implementation of SBP/2– Uses a null password for login– Hard drives stay logged in– Printers log out after a print job– Notify is set at all times