1993.10.22

SUBJECT: SNA article


         *** Distributed SNA 

-User 들의 Distributed TP(Transaction Processing) 요구 의 원인 

     1.Generalized decentralization trends within the organization.  

     2.Technological migration of data processing and communication capability 

     3.Need to provide peer-to-peer connectivity and resource sharing among
     distributed, hostless processing environment 

-배경 

     1.Host-controlled, 중앙집중형 의 네트워크 구조는 batch processing 으로 이
     르게 했고, 일반적으로 계산비용을 높게 하였다.  

     2.Interacitve user 의 information throughput 과 reponse time 이 central
     host 이용을 급격히 떨어뜨렸다.  

     3.빠른 H/W 가격의 하락과 Workstation 의 계산능력 의 증가는 학교, 정부, 회
     사 등을 거쳐 distributed, desktop 의 small-system DB 환경.  

     4.Machine vendor type 또는 지역적인 위치에 상관없이 single-system image 가
     바로 target application 으로 transparent 하게 구현되는 user requirement.  

-등장 

#IBM  은 이러한 distributed TP(transaction pprcessing) 의 요구에 부합하여 IBM
의 SNA(system network architecture) 의 Spec 을 확장하였다.  이러한 distributed
extensions 이 바로 다음과 같다.  

     -APPC(Advanced Program-to-Program Communication)의 기초 

     -SNADS(SNA Distribution Services) 

     -DIA(Document Intercahnge Architecture) 

     -DCA(Document Content Architecture) 

     -DDM(Document Data Management) 

     -LEN(Low Entry Networking) 

$$$ 이 article 은 SNA 에서 APPC 까지의 변천과정을 설명하고 APPC-based distrib-
uted SNA 구조를 정의한다.  

##SNA(System Network Architecture) 

--1974년 발표된 전략적인 communication architecture  로써 communication network
 에서 interconnection 과 resource sharing 을 수행한다.  

--SNA architecture rule sets 

     1.SNA end user:application program, I/O devices, terminal operators.  SNA
      architecture 의 부분은 아니지만, interconnection 과 resource sharing  을
      위하여 SNA 를 사용한다.  

     2.The interface and relationship between SNA and logical network compo-
     nents.  

     3.The logical components required to interconnect and share resources
     among end users.  

     4.The operation sequences for controlling the configuration and operation
     of a network.  

--SNA architecture 는 logical network component 로 NAU(Network Addressable
Uniits) 를 정의하는데, 이것은  end user 가 서로 access 를 할수 있도록 communi-
cation port 를 제공한다.  또한, Network  에 대하여 data 를 보내는 기능을 하며,
하나의 node 에 복수개 가 존재한다.  그리고,SNA network 안에서 unique 한 network
address 를 가진다.  (*end user 와의 단말 창구,network를 관리하기위한 정보나 지
령을 송수신 하는 기능)



Network address;모든 NAU 들이 network 내에서 자기를 유일하게 식별할수 있도록 하
          며 SNA 에서는 NAU 에 network address 라는 번호를 부여 관리함.  net-
          work 내로 보내는 data  에는 수신인/발신인 의 NAU  를 가리키는 netwirk
          address를 추가합니다. Path control network 는 이 수신인 network
          address 를 참조하여 목적하는 Peripheral node  까지 전송합니다.  

          Network address 는 Subaddress 와  element address 로 구성된다.
          VTAM/NCP  에서는 각 자원을 식별하기 위하여 번호를 붙인다.  VTAM/NCP
          는 이번호명을 network address 로 변환하고, sub-address 간의 data 송수
          신에는 Network address 를 사용한다.  


          i)Sub-address:routing table 을 이용하여 특정 subarea 를 식별.
               peripheral node 의 I/O 는 sub-area node 가 control.  data  는 각
               sub-area node 간에서 전송한뒤 peripheral node 로 전송.  각
               peripheral node 나 적용업무 program 이 어느 Sub-area node 에 속
               하는지를 sub-area address 로 표시함.  

          ii)Element address:element routing table 을 이용하여 sub-area 내의
               NAU 를 식별.  NAU  에 대하여 각 sub-area 내에 할당한 고
               유addresss 를 말함.  예를들면,PU4/5 에서 항상 pu는 0,sscp 는 1,
               lu 는 2,3 의 address.  

          cf)BF(boundary function):element address를 peripheral node의 local
          address로 변경.  peripheral address  는 완벽한 network address 로 다
          루어지지 않고 local address 로 다루어 지는데, 이는 network configura-
          tion 의 변경을 용이하게 한다.(network reconfiguration 으로 인한
          network address  의 변경에 대해 peripheral node 는 transparency 를 가
          짐) BF 는 Path control Network  의 일부가 아니므로, peripheral node
          로 접속되는 sub-area node 는 boundary function component 를 가져야함.
          Local address:Sub-area node  는 network address 부터 주변node 의 회
          선, address, SDC address 와 그 주변node 내의 어느 NAU 를 가리키는지를
          찾아낸다. 그리고, sub-area node 가 peripheral node 로 전송하는 data
          에는 local addresss  를 사용한다.  

 NAU 는 3 가지 종류가 있다.  

     1.SSCP(System Service Cntrol Point):Network resource  나 session 의 관리.


     2.PU(Physical Uint):Node 내의 resource 상황을 파악하여 SSCP 에 전달하는 기
     능으로써 VTAM,NCP,단말제어 장치가 이기능을 한다.  

     3.LU(Logical Uint): end user 와의 창구역할.  

--LUs 는 end user 가 SNA network resources  에 접근할수 있도록 하는 logical
port 이다.  PLU(Primary LU) 의 기능은 end user 에게 resources 를 allocate.  여
기서 resources 는 machine processor cycle, real and virtual storage,DASDs(di-
rect access storage devices), I/O devices,terminal and keyboard dis-
plays,queues, database records, and sessions .....  

--Session 은 두개의 NAU 간의 일시적이고, logical connection 으로 아래와 같이 구
분된다.  

 1.LU-to-LU session:Network  의 기본적인목적을 수행한다. user 들의 필요에 따라
 동적으로 설립된다.  


*** 삽입자료 ***



 2.SSCP-to-SSCP:다중 domain 으로 구성된 SNA network 에서 LU 간의  cross-domain
 통신을 수행하며 다양한 SSCP 간의 제어정보를 교환한다.  

 3.SSCP-to-PU:SSCP  는 자신의 domain 에서 각 pu 들과 영구적인 session 을 가져야
 만 한다.  이 session 은 network이 초기화 될때 자동적으로 설립된다. network 관
 리자는 특정 pu 를 잠시동안 사용불가능 하게 할수 있다.  

 4.SSCP-to-LU:SSCP 는 자신의 domain 에서 각 LU 들과 영구적인 session 을 가져야
 만한다.  이 session 은 network user 가 lu 를 access 하기전에 설립된다.
 network 관리자는 특정sscp-to-lu session 을 종료시킴으로써 LU 를 잠시동안 사용
 불가능하게 할수있다.  

 5.PU-to-PU :명백하게 정의되지는 않았지만 , 인접pu 간의 network information 을
 교환한다.  

--PUs 는 SNA 내의 S/W base 의 resource manager 이며 다음을 제공한다 

 1.특정유형의 device  를 사용하거나 관리하는데 필요한 service 젝공.  

 2.communication link 와 같은 physical resources 를 관리하는 service 제공 

 3.node diagnostic information 을 생성 

 4.storage dump, activity trace information 을 가짐.  

 5.SNA node function 구분으로 5,4,2.1,2.0, 1 로 구분 

     *PU5:SSCP S/W  를 지원하는 host node.  3090,3080, 3030, 4300, 9370series 

     *PU4:NCPS/W  를 지원하는 CCU(Communication controller
     unit).3705,3725/3726,3720/3721.  

     *PU2.0:PUCP(PU control point)를 지원하는 3174,3274,3276 같은 Cluster
     Controller.  이 node 는 PU2.0 끼리는 a single link 를 지원하고 이 링크는
     두가지중의 하나가 될수있다.  PUCP(Peripheral Unit control Point) 

-SDLC link:NCP  가 돌아가는  PU4 의 downstream 으로써 remote cluster controller
에 연결.  

-data channel:SSCP 가 돌아가는 PU5 에 직접붙는 local cluster controller 에 연
결.  

 *PU2.1:이 node 는 NN(Network Node) 또는 PN(Peripheral Node) 가 될수 있다.  이
 node 는 advanced cluster node 라고도 하는데 System36, S/38, 5520,8100,IBM PC,
 등우로 PNCP(Peripheral Node Control Point) software 를 지원하며 SSCP 의 subset
 을 수행하여 PU2.1 이 SNA session 을 direct 로 control 한다.  PNCP(Peripheral
 Node Control Point) 

 *PU1:Pre-SNA device or TN(Terminal Node) Non-SNA link-level protocol   을 지원
 ,3271/3272 devices 예)Asynchronous,BSC,SDLC 

--PU, LU 에 이은 세번째 NAU 인 SSCP 는 host 에 존재하는 NAU 로써 network
management 를 책임지며, VTAM(Virtual Telecommunications Access Methed) 의
subset 이다.  SSCP 는 SNA domain 의 controller 이다. SNA 에 서의 domain 은 하나
의 SSCP 와 다른 모든 LU,PU,links 를 말한다.  

--SNA 는 functional layer 로 구성되어 있다.  각각은 특별한 service 를 제공하는
데, layering 의 가장큰 잇점은 functional moduality 의 생성이며 one layer 의 변
화가 다른 layer 에게 영향을 미치지 않는다는 것이다.  그리고 flexibility 를 증가
시키고 logical 하게 서로독립적으로 design,implement, and invoke.  

 1.Physical Control:physically connect DTE to DCE.  

 2.Data link Control:logical link initialization, data transfer, link disconnc-
 tion.  (SNA layer 중 가장 하위의 layer 로써 특정 physical link 상의 두 node 간
 의 data 전송을 책임진다. 이 layer 의 가장중요한 기능은 어쩔수 없이 발생하는 전
 송에러를 막아주고 복원 시켜주는 역활이다) 

 3.Path Control:Network route selection,class of service,message segmenta-
 tion/blocking.  (network 상의 한노드에서 path 상의 옆 node 로 data 를 route
 하는것과 관계있다.) 

 4.Transmission Control:end-to-end connectivity,session activation/deactiva-
 tion,session pacing ( 진행중인 session 의 상태를 유지하고 , session 내의 자료
 흐름의 pace 를 조절하며, 적당한 sequence 에 보내고 받을 message 를 만든 data
 의 unit 를 본다.) 

 5.Data Flow Control:correlation of data exchange,flow synchronization during
 session.  (두 NAU 간의 session 이 성립되어 있는 동안 data flow 의 전체적인 보
 전과 관계 있다.  이 것은 send 와 receive 의 mode 를 결정하고, 관계된 message
 의 group 을 관리하며, 사용할 reponse mode 의 type 을 결정한다.) 

 6.Presentaion Services:format data for various presentation media,syntatic,se-
 mantic data representation.  

 7.Transaction services:end-user logical interface.  

--SNA functional layer 는  크게 두가지로 나누어 진다.  

 1.NAUs:상위 4개 layer 

 2.path control network:하위2개의 layer 


--Layer 들간의 communication 에는 2 가지 type 으로 나눔.  

 1.Communication Between adjacent layers:인접한 layer  간에 일어나는 physical
 communication 

 2.Peer-to-peer Communication:두 communication node 에서 paired layer 간에 발생
 하는 logical communication.  

--The construction of SNA message unit 

 :SNA node 내에서여러 종류의 layering 을 거쳐서 SNA message unit 가 구성되며 이
 는 highest operative layers 로 부터 lower-layer protocol 의 header  가 추가되
 어 encapsulation  된다.  network 내의  인접 node 에서도 동일한 방법으로
 recognize, decapsulate, 등으로 실행.  

--RU(Request/Response Unit) 

 1.end user의 network control information을 가지고 있는 기본적인 SNA message
 unit.  

 2.PU5, 2.1, 2.0, 1 node 내에서의 layer4-7 중의 하나에서 조립된 field formatted
 binary data 로 구성됨.  

--FMH(Fuction Management Header) 

 1.LU1,6.0 , 6.1, 6.2 와 같은 어떤 lu session type 에 대하여  layer 6 는 FMH 를
 만들수가 있다.  

 2.multiple device LU 에 대하여 end user destination device 의 selection 과 같
 은 precise instruction 이나 compression,compaction, or output instruction 같은
 specific data operation  을 수송하는(convey) session 내에서, FMH 는 control
 information 을 전달하는 하나의 mechanism  이다.  

--RH(Respose/Request Header) 

 1.layer 4,5,6 에 의해서 만들어 진다.  

 2.convey and enforces session-unique profiles and protocols.  

--TH(Transmission Header) 

 1.node routing 를 위하여 path control 에서 사용된다.  

 2.layer 3 에 의해서 구성된다.  

 3.VR(VIrtual Router) Transmission Priority(TP) definition base 의 다양한 Class
 of Service(COS) level 을 지원한다.  

--LH(Link Header),LT(Link Trailer) 

 1.layer 2 는 LH 로써 PIU 를 encapsulate 한다. 이 결과가 BLU  이다.  

 2.만약 BLU가 SDLC link 로 traverse  하면, 이것은 SDLC frame 을 define 한다.
 만약 layer 2 link protocol 이 SDLC 가 아니면,(token ring) PIU 는 적절한 layer
 2 protocol header 와  trailer 로써 encapsulate 된다.  

--Centralized SNA network evolution 

 :SNA network  는 애초에 simple, tree oriented, single-host, single-CCU 의 환경
 이었으나 major enhancement 가 제공.  

 1.host  내에 VTAM 의 정의로 application 과 sub-system 으로부터의 과도한
 network overhead function 과 pre-SNA access method 의 기능을  합병, 정리하였
 다.  

 2.CCU 내에서의 NCP 의 정의로서 pre-SNA 환경에서 없었던 S/W programmability 를
 제공.  

 3.어느정도의 device 와 protocol dependency   를 elimination.  

 :1976년, IBM 은 VTAM 과   NCP 를 위하여 ACF(Advanced Communication Function)
 을 빌표.  이 ACF/VTAM 과 ACF/NCP 는 host 에 존재하는 MSNF(Multisystems
 Networking Facility) 로써, multi-host 를 define, muti-CCU networks(multi-do-
 main network) 할수있는 능력을 제공.  

 :1979년, SNA network connectivity 의 extend.  

 1.remote NCP  뿐만아니고, local NCP 사이에서도 cross-domain link 

 2.Paralell links between adjacent NCPs 

 3.Logical consolidation( 합병 ) of adjacent-NCP links into Transmission
 Groups(TGs) 

 4.Multiple and alternate routing between end-point subarea nodes over Explicit
     Routes(ERs), Reverse Explicit Routes(RERs) and VRs(Virtual Routes) 

 :1983년, IBM 이 SNI(SNA Interconnection) 를 발표 

 1.cross-domain network 의 logical extension 으로 end-user application program
 과 devices 가 distinct , separate SNA network 로 부터 access 를 할수있게 한다.


 2.interconnected SNA 에서 각각은 unique nameing, addressing, intenal network
 management procedure amd protocol 을 갖는다.  

 3.gateway NCP 는 물리적으로 두개의 SNA 를 연결하고, 각 network  을 위해 two
 sub-address 를 갖고있으며, gateway VTAM  은 양쪽에 존재할수 있다.  

SNI 의 전략적 목적과 전술적 목적은 다음과 같다.  

 1.strategic objective:분리된 network 을 연결하고,각각은 내부적으로 unique
 global naming and addressing conventions를 지원,cross-network connectivity and
 transparent resoure sharing 를 제공.  

 2.tactical objective: Remove addressing constraints from large SNA networks.
 이것은 SNI 를 통하여 연결된 sub-network 내에서 network address 를 몇개의
 fields 로 나눔으로써 가능하다.  

 그당시에는 16-bit  가 MAXSUBA 또는 network 당 최대 sub-area 수 와 sub-area 당
 element address 수 로 나눔.  

 :1984년, IBM 은 ENA(Extended Network Addressing) 을 소개.  

 1.ENA 는 single network address space  를 최대 255 sub-area 와 sub-area 당
 32,000 element address 로 나눔.  따라서 single SNA network 당 8.35million
 element address 를 지원.  

 2.ENA 는 larger SNA networks 에서 addressing constraints 를 경감.  

 3.이기간 동안의 추가적인 SNA 기능.  

     -Virtual storage constraint 의 relief 가 API 를 통하여 ACF/VTAM 과
     communication 을 하기위하여 31bit address 로써 2GB 의 virtual memory을 사
     용하여 MVS/XA(Multiple virtual storage/extended architecture)실현.  

     -Native Virtual Machine/Support(VMSP) SNA 를 지원, 이는 VM/370 OS  하에서
     돌아가는 application program 은 자연적으로 SNA 를 통하여 communication.  

     -31 dowmstream lines 을 지원하는 model 3710 network concentrator 가 발표
     됨.  

     -Asynchronous, 3270 BSC, CCITT X.25 를 지원하는 protocol converter  가 발
     표됨.  

     --APPC SNA:subarea node connectivity, routing and addressing  의 발전에도
     불구하고, SNA network 는 dummy 와 host-resident application 와의 연결이라
     는 고전적인 방법으로 최적화 되어왔다.  

     :application subsystem, VTAM,NCP buffer size,ERs 와 RERs VRs 상의 Path
     control network routing 의 dispatch algorithm, session-pacing technique
     을 포함한 모든 global design parameters 들이 dumb device 와 host 간의 지속
     적인 연결에 촛점이 맞추어 졌다.  


     :이 고전적인 networks 는 nonhost,standalone, data processing subnetworks
     에 제때에 access 를 제공하는것을 생각하지 않았다.  그러나, 오늘날,
     end-user environment 는 pc 와 다른 hostless 에 의해 점점 특징을 갖고 발전.
     즉, network 내에서 dummy terminal elmuation device, standalone data
     processing machines, or file transfer nodes 로서 dummy terminal 이 바뀌게
     되었다.  마지막 두개의 small-system node 의  특징이 고전적인 SNA archit-
     encture design 을 무시하였고 , 

     :고전적인 시스템속에서 distributes, small system 을 지원하기위한 IBM 의 전
     략적인 대응이 sub-area network 이 APPC 로 발전이다.  

     :APPC 는 SNA architecture 의 distributed extension 으로 LU6.2 의 operation
     rule 을 정의한다.  LU 6.2 는 SNA LUs  의 program-to-program category의 멤
     버로써 SNA architecture 의 지속적인 발전물이다.  

     LU6.2 structures an API to port-distributed application transaction
     programs and enable program-to-program access and resource sharing.  

 :APPC API  는 ATPs 와 APPC 간의 structured protocol boundary 를 define.  LU
 6.2 는  SNA layer 6,5,4, 의 service 를 invoke 하고 ATP 는 SNA architecture 상
 에서는 external 이다.  

 :ATPs 는 API 상에서 APPC 로 verbs 라 불리는 명령어 set 를 통하여 communication
 한다.  verbs 는 distributed ATPs communicate 상에서 conversation 을 구성하는
 distributed processing programming statement 이다.  

 :conversation 은 LU 6.2  session 의 serialized time slice segment 를 나타내는
 것으로써, interprogram communication 을 가능하게 하기위하여 LU6.2 resources 로
 써 ATPs(Application Transaction program) 에게 제공된다.  

 *conversation  은 단지 peerATP 간에 인식되어 진다.  *인접한  APPC(LU6.2) 간의
 session 은 SNA layer 6,5,4 를 invoke 하고 ATPs 에게 conversation resources 를
 제공한다. lu 6.2 는 pu5 와 pu2.1 에서만 지원.  *SNA path control network 는
 underlying SNA layer 3,2,1 connectivity 제공.  

 :APPC 와 ATPs  간의 structured protocol boundary 로 정의되는  API 는 

 1)distributed interprogram environment 에서의 standard transaction protocol
 boundary 를 제공한다.  

 2)underlying APPC session 과 parh control network 환경의 intricacies(뒤얽힘)
 에 대해 proceed transparent 한  interprogram communication 을 허용.  

 3)network 문제로부터 application developer 를 분리시킨다.  


 :APPC API 에 pass 된 verb statement 는 다음으로 구성된다.  

     1)Basic Conversation Verbs 

     2)Mapped conversation Verbs 

     3)Type-independent conversation Verbs 

     4)Control operator Verbs 

 :Program  과 APPC  사이에 모든 verbs 가 통과되는 반면에 단지 conversation
 verbs 가 LU6.2 session 상에서 lu 간에 전달된다.  

 1)Basic Conversation:LU6.2 에 의해 가장 기본적인 service 에 해당하는 LU
 STPs(service transaction program) 을 위하여 사용된다.  

 LU STPs 는 다음을 포함한다.  

 -SNADS:SNA distribution services 

 -DIA:Document Interchange Architecture 

 -CNOS:Change number of services model 

 -Resync Mode:Resynchronization 

 또한, LU STPs 는 end-user ATPS 를 위하여 추가로 protocol boundary 를 제공할수
 있다.  예를들면 basic conversation verbs 는 Mapped conversation verbs의 진행중
 에 나타낡수도 있다.(can be issued).  

 basic conversation verbs 와 각각의 기능 

 ALLOCATE:logical 하게 두개의 TP 을 연결하는 conversation 을 시작하고, allocate
 한다.  

 CONFIRM:local 에서 remote TP 로 confirmation request 를 보냄. 이때 lcoal TP 는
 두개의 TP 의 sync 를 위해 응답을 기다림.  CONFIRMED:confirm verb  를 보낸 TP
 에게 confirmation reply 를 보냄. 이것은 local 또는 remote TP execution 의
 synchronization을 위해 보냄.  

 DEALLOCATE:TP 로 부터 conversation 을 끝내고 , 또는 deallocate 

 FLUSH:local lu  로부터 모든 buffered data 를 보낸다.  

 GET-ATTRIBUTES:local and remote lu name 과 conversation synchronization 과 같
 은 conversation-specific information 을  return 한다.  

 POST-ON-RECEIPT:data, conversation status, request for confirmation or sync
 point processing 과 같은 information 이 receive 할 TP 를 위한available 한 특정
 conversation 의 위치를 요청.  

 PREPARE-TO-RECEIVE: data  를 받은 TP 를 준비하기위하여 send 에서  protocol 의
 receive states 까지의 conversation 을 change,underlying LU ses-   conversation
 sion(SNA layer 5 의 data flow control) 은 half-duplex flip-flop   을 지원한다.


 RECEIVE-AND-WAIT:conversation 이 도착하기를 기다리고 연속적으로 information 을
 받는다.  

 RECEIVE-IMMEDIATE:특정 conversation에 available 한 어떤 information 을 받는다.


 만약 아무것도 available 하지 않다면, 이 verb 는 information 이 도착하기를 기다
 리지 않는다.  

 REQUEST-TO-SEND:local TP  는 remote TP 에 게 local 이 send state 의 conversa-
 tion 에 들어가기를 요청한다고 알려준다.  

 SEND-DATA:local 에서 remote TP 에게 data 를 보낸다.  

 data format은 GDS(general data strea) 라고 하는 하나의 lu6.2 data stream 하에
 서 logical records 에 정의되어 있다. GDS logical record 는 length field(2byte)
 와 data field(0 - 32765 byte)를 포함.  

 SEND-ERROR:local  에서 remote TP 로 detect-error notification 을 보냄.  

 TEST:local lu  에 의해서 받은 conversation 이  posted 인가 아니면, "RE-
 QUEST-TO-SEND" 인가 test.- 

2.Mapped conversation:이것을 사용하는 TP 는 basic conversation 보다 GDS-defined
data stream 의 format 에 맞게 conversation 상에 보내진 data 는 확인할 필요가 없
으므로 사용하기가 쉽다.  특별히 mapped conversation 상에서 보내진 TP 는 GDS
logical length field 로서 prefix data 가 필요없고 send state 를 두고 보내는
logical record 도 완전하게 할필요가 없다.  

 1.두개의ATPs 간의 conversation 을 지원하기위해 design  되었고 근본적으로 basic
 conversation verbs 로써 동일한  set of verbs 이다.  syntax 로서는 mapped
 conversation verbs 는 prefix "MC" 로 시작.  반면에 basic conversation 는
 "ALLOCATE" 와 "DEALLOCATE" 와 "MC-DEALLOCATE" 의 verbs 로서 제한.  

 2.특별히 이 mapped verbs  는 higher-level-language 로 씌어진 application
 program  에 적합하다.  왜냐하면 이 verbs 는 data mapping 을 지원하며 GDS
 mapping 과  application 에 투명한 logical record format 을 위한 요구사항을 만
 든다.  

 3.Type-independent Verbs: Basic   과 mapped conversation 을 둘다 지원하고
 Syncpoint 와 Backout processing 을 포함한다.  

 4.Control operator verbs 는 control operator transaction program  들이 

     -local lu 와 pu resources 의 define 

     -lu6.2 session 의 시작 

     -CNOS 같은 modification sequence 를 통하여 session 을 control 위의 3 가지
     를 하기위하여 structured protocol boundary 를 정의한다.  

     -APPC API 를 경유하여 3개의 주요 verbs 가 있다.  

     -APPC 는 9 개의 conversation verbs 의 base set 을 지원,  각 lu6.2 는 그
     base set 을 지원해야한다.  또한 lu6.2 는 unique 한 product implementation
     을 위하여 몇가지 option set  도 정의한다.  

     -APPC 는 session 중에 Base set 과 indentical option sets 둘다 지원할때만
     peer lu verb option-set communication 을 허용한다.  

Revision History
Created              on Oct  22 ,1993