Be well-being !!

블로그 > Jackylee's Network 이야기

http://blog.naver.com/jackylee08/60039664869

Netscreen 5GT Policy Based 방식 VPN 셋팅방법입니다...

Netscreen 초기 설정 기본 셋팅

1. Netscreen 초기 설정

콘솔연결해서 다음과 같이 명령어를 입력한다.

ns5gt-> unset all 모든 config 삭제

Erase all system config, are you sure y/[n] ? Y Y 입력

ns5gt-> reset 시스템 리부팅

Configuration modified, save? [y]/n n N 입력

System reset, are you sure? y/[n] y Y 입력

장비가 초기화 되면서 리부팅한다.

2. 초기화된후 기본 셋팅

초기화가 되면 기본 접속ID/Password는 netscreen/netscreen이다

각 인터페이스에 맞게 셋팅을 한다.

ns5gt-> set interface trust ip 192.168.10.1/24 내부IP설정

ns5gt-> set interface untrust ip 211.219.xxx.xxx/27 공인IP설정

ns5gt-> set route 0.0.0.0 0.0.0.0 gateway 211.219.121.126 기본 Routing설정

                                                                                                    (공인gateway IP)

ns5gt-> set int trust manage management service 선택      

ns5gt-> set int untrust manage                    management service 선택      

PC에 IP를 셋팅후 DNS로 ping 확인

Ping test 정상이면 Netscreen에 NAT설정 완료

Netscreen 설정방법(Web UI)

WEB를 띄워서 주소창에 Netscreen IP(192.168.10.1 ->trust IP)를 입력하면 초기화면이 나오는데 세번째를 선택 넘어간다 (이미 기본 설정값은 콘솔작업으로 마침)

-> Next

ID와 Password는 변경없으므로 netscreen/netscreen -> Login

Network > Interfaces

해당 인터페이스 상태 확인함

Network > Routing > Destination

초기 라우팅 상태 확인함

Netscreen VPN 설정방법 (Policies Based VPN 방식)

- 장비셋팅은 외부에 단독으로 설치하는곳을 기준으로 작성함.(장비명:NS5GT)

1. VPNs Gateway 설정

VPNs > Autokey Advanced > Gateway > New

-Gateway Name : 상대방 연결될 장비 Gateway 이름설정

-IP Aaddress/Hostname : 상대방 장비 Gateway IP입력(상대방 Untrust IP 설정함)

-Preshared Key : VPN GW 서로간(peer-to-peer)에 최초 인증시 필요한 Key 입력

(양쪽 똑같이 설정)

-Outgoing Interface : Untrust로 설정함(일부는 자동으로 Untrust로 설정될때 있음)

VPNs > Autokey Advanced > Gateway > New > Advanced

Security Level : Preshared Key를 위에서 설정한 암호화 알고리즘을 사용하여 암호화

                        하여 VPN Tunnel간의 인증을 한다. 같은 Netscreen이면 Standard,

                        이기종간의 VPN장비이면 Custom을 선택 양쪽 장비를 같은 값으로 맞

                        춘다.

 2. VPNs IKE(Internet Key Exchange) 설정

VPNs > Autokey IKE > New

-VPN Name : 상대방 VPN과 연결되는 이름설정

-Remote Gateway : 위에서 설정한 VPN Gateway 선택

Security Level : IPSec 암호화 알고리즘 지정(같은 Netscreen이면 Standard)

3. Objects 설정

Objects > Addresses > List > All zones

-VPN Policies를 설정하기전에 Address zone을 설정해야한다.

-위 그림은 모든 zone을 보여준다.

-Zone에서 Trust(Local 내부망), Untrust(Remote 내부망)을 만들어주어야 한다.

Objects > Addresses > List >Trust > New

-Address Name : Local Network이름 설정

-IP Address/Domain Name : Local Network IP 대역지정

-Zone : Local Network 이르모 Trust로 설정

Objects > Addresses > List >Untrust > New

-Address Name : Remote Network이름 설정

-IP Address/Domain Name : Remote Network IP 대역지정

-Zone : Remote Network 이니까 Untrust로 설정

-All zones의 내용이다.

-Trust 와 Untrust zone 셋팅한 내용을 알 수 있다.

4. Policies 설정

Polices > From Trust To Untrust > New

-Name (optional) : VPN 정책 이름 설정

-Source Address : Local Network 대역지정 (위에 Objects > Addresses

                             설정된값 지정)

-Destination Address : VPN 통신을 하고자 하는 Remote Network 대역지정

(위에 Objects > Addresses 설정된값 지정)

-Action : Deny, Permit, Tunnel 중 Tunnel 선택

-Tunnel : 미리 만들어 둔 VPN Tunnel (VPNs IKE에서 만듬)

-Modify matching bidirectional VPN policy : 체크하면 Outgoing VPN 정책을 설정하면

                                                                  자동으로 Incoming VPN 정책이 생성됨.

-Logging : 체크하면 Log를 확인할 수 있다.

-Policies 셋팅이 완료되면 위와 같은 화면을 볼 수 있다.

-정책은 순서대로 이루어진다. VPN통신을 하기 위해서는 정책의 순서를 바꿔줘야한다.

Move 의 화살표클릭

-Move > 화살표 하면 클릭한 정책을 어디에 둘것인가가 보인다. Any 보다 앞에 있어야 하므로 위에 화살표에 클릭한다.

정책순서가 바뀐것을 볼 수 있다.

Remote 장비 VPN Trust IP Ping test한 결과이다.

 Remote Host에 Ping test한 결과이다.

원본 위치 <http://blog.naver.com/PostList.nhn?blogId=kkomzi7179>

원본 위치 <http://blog.naver.com/PostView.nhn?blogId=dusun4&logNo=34670204>  

Page 1

From IEEE P1073.3.2 / D1.0

Page 1 of 219

Highlights and excerpts from the …

IEEE 1073.3.2

Standard for

Medical Device Communications –

Transport Profile –

IrDA Based –

Cable Connected

Allen Farquhar, Chair

Alaris Medical Systems

Todd Cooper

Alaris Medical Systems

Ken Fuchs

Siemens

Harald Greiner

Hewlett-Packard

Kenneth Hall

SpaceLabs

Dick Myrick

Hewlett-Packard

Daniel Nowicki

GE-Marquette Medical Systems

Paul Schluter

GE-Marquette Medical Systems

Ward Silver

Physio-Control

Lars Steubesand

Hewlett-Packard

Jan Wittenber

Hewlett-Packard

Other individuals who have contributed to this document:

Frank Enslin

Hewlett-Packard

George Kriegl

GE-Marquette Medical Systems

Tom Luteran

Hewlett-Packard

Bob Meijer

Alaris Medical Systems

Carol Pellegrini

Alaris Medical Systems

These notes highlight the key features of the IEEE 1073.3.2 Medical Information Bus,

Draft 1.0, and were prepared by Paul Schluter for a MIB tutorial at the HL7 Winter

Working Group Meeting in San Diego, California, on January 25, 2000. Draft 1.0 was

approved as a new standard by the IEEE-SA Standards Board on January 30, 2000.

Copyright © 1999, 2000 IEEE.

These notes are reproduced for purposes of IEEE standardization activities.

Page 2

From IEEE P1073.3.2 / D1.0

Page 2 of 219

Reasons for developing the 'new' IEEE 1073.3.2 lower layers

The earlier IEEE 1073.4.1 Physical Layer and IEEE 1073.3.1 Transport Profile

were not widely adopted by the medical community due to

• complexity and cost
• difficulty in redesigning or bridging to legacy devices
• limited availability of hardware and development tools

  Devices with proprietary and mutually incompatible physical interfaces and

  protocols continued to proliferate, forcing system vendors to develop and

  validate numerous customized medical device interfaces.

  Yet, the demand for automated medical device data still exists … and is

  growing rapidly!

  Goals and Objectives for IEEE 1073.3.2

  Facilitate compatibility with existing medical device communications designs,

  so as to minimize design risk, contain product costs, and simplify field

  upgrades.

  Specify hardware and software elements that are available from multiple

  vendors.

  Make use of other computer industry communication technologies and

  standards to decrease cost and design risk.

  Meet the requirements of IEEE Std 1073 and related upper layer standards.

  
  

  Page 3

  From IEEE P1073.3.2 / D1.0

  Page 3 of 219

  Key features of IEEE P1073.3.2 Standard for

  Medical Device Communications –

  Transport Profile - IrDA Based – Cable Connected

  IEEE P1073.3.2. Physical Layer …

• RS-232

  - widely used by medical devices

  - low-cost, readily available

• DC power delivery

  - can power devices and adapters

  - three power options

• unpowered DCC/BCC

  detection

  - ease-of-use; fault detection

• 10BASE-T Ethernet

  - high-speed devices

  [10BASE-T reserved for future]

• RJ-45 connector, CAT-5 cable

  - easy-to-use, low-cost connector

  - mandatory at bedside (BCC)

  IEEE P1073.3.2. Transport Protocols …

• IrDA protocols

  IrLAP, IrLMP, and TinyTP

  - widely used standard

  - unique device identification

  - can support multiple upper-layer

  protocols (MDDL, SNTP, …)

  Multiple upper layer protocols (IrDA Service Access Points)…

• Medical Device Data Language (MDDL)
• Simple Network Time Protocol (SNTP)
• Other upper layer protocols (ASTM E-1394)?

  Also, promotes the use of IrDA wireless …

  
  

  Page 4

  From IEEE P1073.3.2 / D1.0

  Page 4 of 219

• IrDA (optical)

  - portable device connectivity

  - home use (e.g. glucometer)

  
  

  Page 5

  From IEEE P1073.3.2 / D1.0

  Page 5 of 219

  Figure 1 –Connection topology with a local host

  Figure 2 –Connection topology with a remote host

  B C C

  D C C

  D e v ic e ( 1 )

  . . .

  D C C

  D e v i c e ( 2 )

  D C C

  D e v i c e ( n )

  L o c a l h o s t c o m p u t e r

  I E E E 1 0 7 3 .3 .2

  n e t w o r k

  B C C

  B C C

  . . .

  D C C

  D e v i c e ( 1 )

  . . .

  D C C

  D e v ic e ( 2 )

  D C C

  D e v i c e ( n )

  R e m o t e h o s t

  c o m p u t e r

  N e t w o r k

  I E E E 1 0 7 3 .3 .2

  n e t w o r k

  N e t w o r k in t e r f a c e

  B C C

  B C C

  B C C

  . . .

  
  

  Page 6

  From IEEE P1073.3.2 / D1.0

  Page 6 of 219

  A.1.5

  Physical configurations (without 10BASE-T)

  BCC

  IrDA

  DCC

  RS-232

  BCC

  RS-232 + BPWR

  DCC

• IV pump
• other devices
• urimeter

  IrDA

  BCC

  RS-232 + BPWR

  device protocol

  protocol converter

  device interface

• proprietary
• IEEE 1073.4.1

  DCC

  IrDA

  BCC

  DCC

  RS-232 + BPWR

  RS-232 + DPWR

  electrical isolation

  IrDA

  IrDA

  BCC

  DCC

  RS-232 +

  BPWR

  RS-232 +

  DPWR

  Fiber-optic line extender

  infrared or RF link

  IrDA

  IrDA

  Notes: BPWR is DC power provided by BCC

  DPWR is DC power provided by DCC

  
  

  Page 7

  From IEEE P1073.3.2 / D1.0

  Page 7 of 219

  Tables A.3 and A.4 [combined] – Modular connector pin assignments

  BCC

  Pin and

  signal

  direction

  Function

  DCC

  bRD+

  1 ⇐

  DPWR / 10BASE-T

  dDPWR / dTD+

  bRD-

  2 ⇐

  BCC sense / 10BASE-T

  dCS- / dTD-

  bCS+ / bTD+

  3 ⇒

  DCC sense / 10BASE-T

  dRD+

  bGND

  4 ⇔

  Signal Ground

  dGND

  bRxD

  5 ⇐

  RS-232

  dTxD

  bCS- / bTD-

  6 ⇒

  DCC sense / 10BASE-T

  dRD-

  bTxD

  7 ⇒

  RS-232

  dRxD

  bBPWR

  8 ⇒

  BPWR

  dBPWR

  The RxD, TxD, and GND signals support the RS-232 serial data interface. BPWR and

  DPWR provide power for a line accessory or a DCC. CS and DPWR provide connection

  sensing.

  This standard is compatible with a 10BASE-T interface, supported by the RDand TD

  signals (pins 1-2 and 3-6). A BCC port may be designed to support the ability to detect

  an IEEE 1073.3.2 (RS-232) connection or a 10BASE-T connection, and to communicate

  with either device. [However, 10BASE-T functions for BCCs and DCCs are currently

  out of the scope of the IEEE 1073.3.2 standard.]

  A BCC can sense the connection of a DCC by testing the resistance across its bCS+

  and bCS- pins. The alternative names bTD+ and bTD- indicate the 10BASE-T transmit

  data function.

  A DCC may provide power on its dDPWR line to a line-extender or communications

  adapter. A DCC can sense its connection to a BCC by testing the resistance between its

  dDPWR and dCS- pins. The alternative names dTD+ and dTD- indicate the 10BASE-T

  transmit data function.

  
  

  Page 8

  From IEEE P1073.3.2 / D1.0

  Page 8 of 219

  1

  8

  7

  5

  4

  8

  7

  5

  4

  bBPWR

  bGND

  dBPWR

  dGND

  100 Ω

  preferred

  0 Ω

  permitted

  100 Ω

  preferred

  0 Ω

  permitted

  BCC

  Detector

  (optional)

  DCC

  Detector

  (optional)

  DCC

  Power

  (options)

  2

  3

  6

  1

  2

  3

  6

  BCC

  Power

  (options)

  BCC

  DCC

  dDPWR

  dCS-

  Figure A.6 - Schematic of pin assignments and functions (without 10BASE-T)

  1

  2

  3

  6

  1

  2

  3

  6

  BCC

  DCC

  Figure F.1 – 10BASE-T Ethernet (informative)

  
  

  Page 9

  From IEEE P1073.3.2 / D1.0

  Page 9 of 219

  A.6

  BCC and DCC power delivery

  There are three power delivery options:

  a) Zero-power The BCC or DCC does not provide power.

  b) Low-power The BCC or DCC offers power levels that are typically

  provided by the parallel connection of RTS || DTR or a single

  RTS or DTR pin of a standard RS-232 communications port.

  This can be used to power line isolators and extenders.

  c) High-power The BCC or DCC offers DC power of +5.0 V ±5% @ 100 mA.

  This can be used for powering a wide range of devices that

  have modest power requirements.

  Annex B

  Maximum cable length

  Table B.1 –MIB cable lengths using #24 AWG CAT-5 cable

  Cable characteristics

  Maximum length

  ANSI/TIA/EIA-232-F

  a

  CAT-5 UTP @ 84 pF/m, 2500-100 pF

  b

  28 m

  DC Power (100 mA from +4.75V high-power BCC)

  to +4.50 V delivered to DCC

  to +4.35 V delivered to DCC

  12 m

  20 m

  a

  The capacitance per unit length estimates used above are based on CAT-5 UTP cable with a mutual

  capacitance C

  m

  = 56 pF/m. The capacitance for TxD and RxD with all other pins tied to GND is C

  s

  =

  1.5*C

  m

  = 84 pF/m. A terminating capacitance C

  st

  = 100 pF is allocated for the receiver and connector

  capacitance on RxD.

  b

  The capacitance for TxD and RxD for a shielded twisted pair cable with a foil shield with all other pins and

  shield tied to GND is C

  s

  = 1.8*C

  m

  = 100 pF/m. This would result in a maximum cable length of about 24

  m.

  Based on the results shown in above, a 20 meter CAT-5 cable will support any IEEE

  1073.3.2 capabilities for any off-the-shelf RS-232 transceiver that is operated at data

  rates specified with a load (shunt) capacitance of 2500 pF.

  
  

  Page 10

  From IEEE P1073.3.2 / D1.0

  Page 10 of 219

  
  

  Page 11

  From IEEE P1073.3.2 / D1.0

  Page 11 of 219

  Annex D

  RJ-45 to DB-9 modular adapters

  [1]

  [2]

  [3]

  [4]

  [5]

  [6]

  [7]

  [8]

  BCC to DTE DB-9M [ fiber optic ] DTE DB-9M to DCC

  [1]

  [2]

  [3]

  [4]

  [5]

  [6]

  [7]

  [8]

  dDPWR

  dCS-

  dRD+

  dGND

  dTxD

  dRD

  dRxD

  dBPWR

  bRD+

  bRD-

  bCS+

  bGND

  bRxD

  bCS-

  bTxD

  bBPWR

  nc

  nc

  nc

  GND [5]

  RxD [2]

  nc

  TxD [3]

  RTS [7]

  DTR [4]

  nc

  nc

  nc

  [5] GND

  [2] RxD

  nc

  [3] TxD

  [7] RTS

  [4] DTR

  line-extender

  *

  *

  * connection to DTR is optional

  Figure D.1 – Sample adapters for a line extension

  DTE DB-9F to BCC [ MIB Cable ] DCC to DTE DB-9F

  dDPWR

  dCS-

  dRD+

  dGND

  dTxD

  dRD-

  dRxD

  dBPWR

  [1]

  [2]

  [3]

  [4]

  [5]

  [6]

  [7]

  [8]

  bRD+

  bRD-

  bCS+

  bGND

  bRxD

  bCS-

  bTxD

  bBPWR

  DCC detector

  GND [5]

  RxD [2]

  DCC detector

  TxD [3]

  RTS [7]

  DTR[4]

  [7] RTS

  BCC detector

  [5] GND

  [3] TxD

  [2] RxD

  nc

  [4] DTR

  *

  *

  * connection to DTR is optional

  Figure D.2 – Sample adapters for a DCC or BCC port

  
  

  Page 12

  From IEEE P1073.3.2 / D1.0

  Page 12 of 219

  Annex H

  Non-isolated BCC and DCC design examples

  1K

  dCS-

  8

  7

  5

  4

  8

  7

  5

  4

  bBPWR

  bGND

  dBPWR

  dGND

  100 Ω

  preferred

  0 Ω

  permitted

  100 Ω

  preferred

  0 Ω

  permitted

  DCC

  Power Out

  1

  2

  3

  6

  1

  2

  3

  6

  BCC

  Power Out

  (options)

  BCC

  DCC

  dDPWR

  +5V

  10K

  100K

  DCC

  Detector

  BCC

  Detector

  bCS+

  bCS-

  Note: ESD and EMI/RFI suppression circuitry for

  signal pins is not shown.

  Figure H.1 – Non-isolated BCC and DCC port implementation

  
  

  Page 13

  From IEEE P1073.3.2 / D1.0

  Page 13 of 219

  Annex I

  Isolated BCC design example

  +5V

  +5V

  +5VI

  +5VI

  +5VI

  n

  +5V

  Current

  Limiter

  n

  Note: ESD and EMI/RFI suppression circuitry

  for signal pins is not shown.

  100 Ω

  +5V

  n

  1K

  4.7K

  8 bBPWR

  4 bGND

  7 bTxD

  5 bRxD

  1 bRD+

  2 bRD-

  3 bCS+

  6 bCS-

  preferred

  0 Ω

  permitted

  n

  n

  n

  Figure I.1 – An isolated BCC port implementation with data transmission,

  connection sensing, and supplied power

  
  

  Page 14

  From IEEE P1073.3.2 / D1.0

  Page 14 of 219

  IEEE 1073.3.2 Physical Layer Summary

  Point-to-point cable connection between BCC and DCC

• data transmission using RS-232 over UTP CAT-5 cable
• 8-pin RJ-45 modular connector required at BCC interface

  Additional physical layer capabilities

• Several power delivery options for BCC and DCC
• Unpowered BCC and/or DCC detection
• Compatible with 10BASE-T RJ-45 pinout standard

  Additional physical layer characteristics

• RS-232 signaling speeds: 9600 (default), 19200, 38400, 57600 and 115200

  Baud.

• Octet encoding: start bit, eight data bits, no parity bit, one stop bit.
• Maximum cable length: 20 meters.
• Guidelines for physical media marking and color (yellow).
  
  

  Page 15

  From IEEE P1073.3.2 / D1.0

  Page 15 of 219

  An introduction to IrDA (Infrared Data Association)

  IrDA is an association of over 160 companies world wide.

  IrDA standardizes infrared data communication methods.

  IrDA specifies a set of protocols that was first released in 1994.

  IrDA is already used for communication between personal computers, laptop

  and handheld computers, printers and many other devices.

  IrDA References

  Infrared Data Association at http://www.irda.org

  Serial Infrared Physical Layer Link Specification (IrPhys) v1.2 10nov97

  Serial Infrared Link Access Protocol (IrLAP)

  v1.1 16jun96

  Serial Infrared Link Management Protocol (IrLMP)

  v1.1 23jan96

  'Tiny TP': A Flow-Control Mechanism for use with IrLMP v1.1 20oct96

  Also available: IrCOMM, IrOBEX, IrTran-P, IrMC, IrLAN and IrLITE

  IrDA Software

  Counterpoint Systems Foundry

  http://www.countersys.com

  MPC Data Ltd.

  http://www.mpc-data.co.uk

  Phoenix Technologies Ltd.

  http://www.phoenix.com

  EMBEDnet Inc.

  http://www.embednet.com

  Linux

  http://www.linux.org

  … other companies and platforms are listed at http://www.irda.org

  
  

  Page 16

  From IEEE P1073.3.2 / D1.0

  Page 16 of 219

  IrDA Protocol Stack with MDDL and SNTP

  Layering is consistent with IrDA standards, as shown below.

  Related ISO OSI Layer

  IEEE 1073.3.2 Layer

  Service Access Points 5-6

  SNTP SAP

  MDDL SAP

  Transport

  4

  IrLMP

  IAS

  TinyTP: Tiny Transport Protocol

  Network

  3

  IrLMP: Link Management Protocol

  Data Link

  2

  IrLAP: Link Access Protocol

  Physical Link

  1

  IEEE 1073.3.2 Physical Layer

  The components of the stack are briefly as follows.

  a) Physical layer – defines a standard connector and electrical characteristics.

  b) IrLAP – provides a device-to-host connection for the reliable, ordered transfer of

  data, including device discovery procedures.

  c) IrLMP – provides multiplexing of the IrLAP layer and IAS device information.

  d) Tiny TP – provides flow control on IrLMP connections and negotiated optional

  segmentation and reassembly.

  e) SNTP SAP – a service access point for an optional time synchronization using the

  Simple Network Time Protocol.

  f) MDDL SAP – a service access point for the Medical Device data language, as

  described in other IEEE 1073 standards.

  
  

  Page 17

  From IEEE P1073.3.2 / D1.0

  Page 17 of 219

  IrLAP – IR Link Access Protocol

  Provides device-to-host connection for reliable, ordered transfer of data and

  device discovery procedures.

  BCC and DCC participate as IrLAP 'primary' and 'secondary' stations.

  Each port on a BCC represents a separate instance of the transport profile

  stack.

  Asynchronous framing with data transparency by using byte-stuffing.

  Data integrity assured with a 16-bit CRC-CCITT cycle redundancy check.

  Multi-drop capable (not used by IEEE 1073.3.2 cable-connected devices)

  IrLAP provides

• Station discovery/identification procedure
• Dynamic addressing and conflict resolution
• Negotiation of connection characteristics
• Connectionless and connection-oriented services
• Low-level flow control (TinyTP provides high-level flow control)
• Error detection and retransmission

  BCC

  IrLAP primary

  station

  DCC

  IrLAP secondary

  station

  
  

  Page 18

  From IEEE P1073.3.2 / D1.0

  Page 18 of 219

  IrLMP – IR Link Management Protocol

  Multiplexes service and applications on the IrLAP.

  Link Management Multiplexer

•    

  Provides multiple data link connections over IrLAP.

  Discovery Information: Service hints and Device nickname

• 'Service hints' bits indicate general class of device (e.g. computer, printer,

  etc.)

• For IEEE 1073.3.2, service hints bits 7 (extension) and 12 (IEEE 1073) are

  set.

• Device nickname must start with "MIB" followed by a space:

  e.g. "MIB IV Pump".

  Information Access Service (more on next slide)

• Maintains an information database about device information and services.
  
  

  Page 19

  From IEEE P1073.3.2 / D1.0

  Page 19 of 219

  IrLMP IAS – The Information Access Service

  Serves as the "yellow pages" for device services and applications.

  IAS Object classes and attributes:

• Device: DeviceName, IrLMP Support
• IEEE:1073:3:2 GlobalID, NodeType, PortNumber, PollInterval
• IEEE:1073:3:2 SNTP – Simple Network Time Protocol
•    

  IEEE:1073:3:2 MDDL – Medical Device Data Language

  GlobalID: 64-bit Global Identifier Number (EUI-64) [recommended]

• 24-bit company_id followed by 40-bit extension identifier
• company_id is assigned by the IEEE Registration Authority Committee

  (RAC)

• allows multiple devices of the same type to be distinguished
• facilitates tracking and maintenance within an institution
  
  

  Page 20

  From IEEE P1073.3.2 / D1.0

  Page 20 of 219

  TinyTP – Tiny Transport Protocol

  Provides per-channel flow control and segmentation/reassembly (SAR).

  Provides robust per-channel flow control for multiple IrLMP connections.

  Segmentation and reassembly (SAR) if both ends of the link support SAR

  (negotiated optional capability for IEEE 1073.3.2).

• Negotiated maximum transfer unit (MTU): 64 to 1496 bytes, 1024 bytes

  recommended.

  SNTP SAP – Simple Network Time Protocol

  Optional time-synchronization protocol using SNTP.

  Uses the Internet Simple Network Time Protocol (SNTP) for precision time

  synchronization between DCCs and BCCs.

  The SNTP described in RFC-2030 is a subset the complete Network Time

  Protocol (NTP) described in RFC-1305. Both protocols use the same 48-octet

  message format.

  The DCC periodically sends a SNTP client request to the BCC, which then

  issues a SNTP server reply. The DCC uses the roundtrip 'delay' and 'offset' to

  update its local clock.

• < 1 ms synchronization possible at 9600 Baud.
• < 10 sec synchronization possible with 10BASE-T on same subnet.

  MDDL SAP – Medical Device Data Language

  Provides the Service Access Point for the Medical Device Data Language,

  described in other IEEE 1073 standards.

  
  

  Page 21

  From IEEE P1073.3.2 / D1.0

  Page 21 of 219

  Benefits of the IEEE 1073.3.2 IrDA-based Transport Layer

  IrDA is an industry-standard protocol that is supported on many computation

  platforms and for which source code and development tools are available.

  IrDA provides reliable communication in an 'ad hoc' network environment

  where frequent connections and disconnection can occur.

  IrDA supports multiple channels within a single host-to-device connection

  using protocols that support the reliable, ordered transfer of data with robust

  per-channel flow-control.

  Devices can be uniquely identified, facilitating device inventory management

  and maintenance.

  IrDA provides a foundation for additional upper-layer protocols and services

  that can accommodate new classes of medical devices.

  IrDA makes it relatively easy to explore applications where infrared wireless

  connectivity is appropriate.

  Benefits of the IEEE 1073.3.2 Physical Layer (RS-232, cable-connected)

  Uses RS-232, a simple, low-cost communication technology that facilitates

  compatibility with the majority of 'legacy' medical devices in use today.

  RS-232 is also relatively easy to electrically isolate.

  Compatible with other computer industry communication technologies and

  standards, decreasing cost and design risk. Allowing multiple DC power

  options facilitates this.

  Unpowered DCC and BCC detection promotes ease-of-use and fault detection.

  RJ-45 connector and UTP CAT-5 cable are an easy-to-use, low-cost connector

  and cable technology.

  RJ-45 pinout can support 10BASE-T for future high-speed devices.

  
  

  Page 22

  Filename:

  MIB Tutorial - IrDA-Based Transport Overview

  (Schluter).doc

  Directory:

  C:\1073\1073 (UPDATE2002-02-

  26)\standards\11073-30200

  Template:

  C:\usr\doc\dot\wg5-sm1.dot

  Title:

  IEEE 1073.3.2 / D0.4

  Subject:

  Transport Profile, IrDA Based

  Author:

  Allen Farquhar

  Keywords:

  Comments:

  Creation Date:

  9/14/1999 3:50 PM

  Change Number:

  100

  Last Saved On:

  7/7/2001 8:55 AM

  Last Saved By:

  Todd Cooper

  Total Editing Time: 836 Minutes

  Last Printed On:

  2/26/2002 12:38 PM

  As of Last Complete Printing

  Number of Pages: 21

  Number of Words: 2,183 (approx.)

  Number of Characters: 12,446 (approx.)

     

  원본 위치 <http://72.14.235.104/search?q=cache:PLDFIiGGf5IJ:www.ieee1073.org/standards/11073-30200/MIB%2520Tutorial%2520-%2520IrDA-Based%2520Transport%2520Overview%2520_Schluter_.pdf+IEEE+1073.3.2&hl=ko&ct=clnk&cd=1&gl=kr>