Chappter
3
LCP and the PPP State Machines
이 장에 대해
이 장에서는 일반 PPP상태 매카니즘과 협상에 쓰이는 맨 첫 프로토콜인 LCP(Link Control Protocol), 그리고 모든 PPP연결에대한 파라미터들의 기본적인 기능들을 설명한다.
이 장에서 설명되는 기술들은 이 책의 나머지 장에서 사용되는 것들이다.
PPP Outline
RFC1661에는 그림 3.1에서 보이는 연결 현상을 설명하고 있다. 이들 상태들은 PPP 데몬에서 항상 전체다나 바로바로 수행되지는 않는다. 예를 들어, common ppp-2.3은 9단계 연결 절차를 수행 하지만 이들은 단지 프로토콜 제어를 위해 사용한다. 사실 NCPs(Network Control Protocols)의 초기화는 main link phase state machine에 의해 수행 되기 보다는,인증 모듈에 의해 저절로 수행된다.
+--------------Fall--------------------+
| |
v |
+---------+ UP +------------+
| Dead |------------------------->| Establish |
+---------+ +------------+
^ | Opened
| Down v
+------------+ Fall +-------------+
| Terminate |<---------------------| Authenticate |
+------------+ +-------------+
^ | Success/
| Closing +--------+ | None
+-------------| Network |<--------------+
+---------+
그림 3.1 RFC 1661 연결 형태도
또 다르게 협상시 3가지 기본 과정을 수행하기 위해 - Establish (LCP 협상), Authenticate [ Authentication Protocol 과 Link Quality Management(LQM)], Network(NCP 협상) - 프로토콜을 디자인시에 이들을 레이어별로 고려될수있다. 이 모델에서, 각 레이어는 UP/Down방향으로 인접한 레이어로 그림 3.2와 같이 이벤트를 보낸다. 이러한 레이어들은 PDU에서 사용되는 프로토콜에서 레이어화 되어 있는 것은 아니고, 대신에 순차적으로 수행된다.
+---------------------+
| Network |
+---------------------+
UP/ ^ | Open /
Down | v Close
+---------------------+
| NCP |
+---------------------+
UP/ ^ | Open /
Down | v Close
+---------------------+
| Auth/LQM |
+---------------------+
UP/ ^ | Open /
Down | v Close
+---------------------+
| LCP |
+---------------------+
UP/ ^ | Open /
Down | v Close
+---------------------+
| Physical |
+---------------------+
그림 3.2 PPP 레이별 천이도
여기서 각 단계의 "UP"은 세가지 결과를 나타내고 있다 : 상위 레이어로부터 Open요청, 하위 레이어로부터 UP 이벤트, 현재 레이어에서 파라미터 협상의 성공. 이런 조건들이 충족 되었을때 현재 레이어는 상위 레이어에게 UP 이벤트를 보낸다.
통상적으로 사용자는 어떤 인터페이스를 통해 연결을 요청하거나, Network 인터페이스가 idle인터페이스에 패킷이 쌓이면 다이얼링 요청 메카니즘을 통해 연결을 요청한다. 이때 Open이벤트는 PPP 스택 레이어인 NCP로 그리고 LCP로 보내 지게 된다. 이를 그림 3.3에서 보여 주고있다.
Network NCP Auth LCP Physical
| | | | |
| Open | | | |
|----------->| Open | | |
| |-------->| Open | |
| | |-------->| Open |
| | | |------------>|
| | | | | Dial
| | | | UP |
| | | UP |<-------------|
| | |<--------| Negotiate |
| | UP | Negotiate| |
| UP |<--------| | |
|<----------| Negotiate| | |
Transmit | Negotiate | | | |
begins | | | | |
그림 3.3 다이얼 요청 예
LCP 시작은 physical link가 성립되었을때 수행되어진다. 이 Physical Link는 모뎀을 다이얼하고 다이얼이 수행될 동안 대기하고, ATM 인터페이스상에서 PVC(Permanent Virtual Circuit)를 생성하게 된다. 이런 절차들이 수행되고 나면, 이 인터페이스는 UP이벤트를 LCP로 보낸다.
LCP는 다른 Peer에게 Configure-Request 메시지를 보내면서 협상을 시작한다. peer는 설정 값을 저장하고, LCP는 그때 UP 이벤트를 Authentication레이어로 보낸다. 만약 인증 요구가 있으면, 이 레이어는 인증이 될때까지 동작한다. 그렇지않으면 NCP로 그냥 UP 이벤트를 보낸다.
authentication이 끝나면, 연결은 "UP"이 되었다고 본다.여전히 사용자 data는 이 연결에서는 흐르지 않은 상태다. network 인터페이스들을 UP으로 바꾸기 위해서 연결로 사용자 data를 보낼것이다. 각 네트웍 인터페이스에 대한 NCP는 협상되어 져야 한다. NCP는 단독으로 동작할 수 있고, 네트웍 연결이 UP상태에서는 연결을 끊거나, 연결 할 수도 있다. 종종 이런 연결들 중에는 마지막 NCP가 종료될 때 LCP에 종료 이벤트를 보내므로 연결이 끊어지기도 한다. 그러나 이런 경우는 반드시 이루어 져야 하는 것은 아니다. 만약 시스템 리소스와 사용자 설정이 허가되었다면, 이 연결은 UP으로 될수 있으나, 다른 네트웍 인터페이스에 의해 다시 사용되어 질때 까지는 Idle상태이다.
tear-down상에서, 각 NCP는 저절로 연결에서 종료되고, LCP는 이어서 종료된다. 맨 마지막으로 physical레이어는 implementation-dependent mannner로(hangup telephone 처럼) 종료될것이다. 이러한 절차는 NCP의 종료없이도 LCP의 종료를 수행하기위해 PPP에 대해서는 필요하다. 뿐만아니라, physical 연결 종료시 아무런 통지 이벤트 없이 수행하기위해서다. 이러한 처리는 매우 일반적인 절차로서, 일반적으로 모든 연결 서비스에 tear down하기위해 implementation-dependent handling을 요구한다.
Machine상태 협상
각 레이어는 각기 다른 열가지 상태가 될 수있다. 이런 상태에 대한 내용은 RFC 1661에 나와있는데, 이를 좀더 간단히 상태에 대한 성립과 종료에 대한 설명을 순차적으로 나누어 설명할 것이다.
한 레이어가 UP으로 되는데는 프로세스상에서 두 단계로 구분된다. 첫째, state machine은 현재 레이어보다 하위 레이어에서는 이미 UP이어야 하고 현재 레이어는 시작이 되어진 상태이어야 한다. 이는 0,1,2의 상태가 되며 이때 1은 Open요청을 나타내며, 2는 하위 레이어로 UP을 나타낸다. 이때 Peer와 협상이 필요하고 그 레이어를 사용하기 위해 파라미터 설정이 필요하다. 상태 6,7,8은 Request, Acknowledge, Negative-Acknowledge(Nak),Reject 메시지들이 함께 사용되어 진다. 이는 양방향 동시 협상에 사용되며 이로서 양측 모두 종료가 가능해 진다. 마지막으로 현재 레이어가 상태 9일때는 UP이 된다. 그리고 그 다음 상위 레이어는 이때 시그날이 발생되어 진다. 아래 그림 3.4참조.(아래 다이어 그램은 아주 간단히 나타낸것으로 다양한 타이머 사용과 에러 헨들링은 나타내지 않고 있다.)
Layer down흐름은 그림 3.5에서 간단히 보이고 있는데 단순히 Terminate-Request 메시지를 보내고 Terminate-Acknowledge메시지를 기다릴 뿐이다. 이 과정의 어려운 부분은 해당 peer가 로컬시스템보다 순서상 먼저 종료 초기화를 할것이다. 현재 peer는 layer down으로 처리가 되었지만 로컬은 다음 상위 레이어와 하위 레이어의 상태는 여전히 UP 상태이므로 상태 3,5가 필요하다. 이 다이어그램은 아주 간단히 종료와 state machine과의 중요한 관계를 도식화 하였다.
state machine의 양 방향 모두를 그림 3.6에 나타내었다.이 정보들은 RFC 1661에서 이벤트를 포함하여 그 결과까지도 잘 추려서 나타내었다.
이 다이어그램에서 RXR은 모든 상태에서 무시 되었고 RUC원인에 대한 이벤트 SCJ는 0과 1상태 이다. 이벤트와 결과는 다음과 같다.
*UP 하위 레이어는 Opened 상태
*Down 하위 레이어는 Opened상태를 지났다.(우아한 종료(graceful close)는 예외다.
이 경우 "Down"은 Closing이나 Initial에서 상위 레이어에게 신호하게된다.
또는 Opened에서 Closing이 아닌 다른 상태로 갈때도 마찬가지로).
*Open 상위레이어에 의해 협상을 시작을 요청받는다.
*Close 상위레이어로 부터 종료 요청(Opened상태가 아닐 경우,
state machine의 종료는 LCP Protocol-Reject 생성 보다 우선한다.
*TO+ 타임 아웃 후 재전송
*TO- 타임 아웃; 너무 많은 재전송
*RCR+ Configure-Request 수용 메시지 수신
*RCR- Configure-Request 수용 불가 메시지 수신
*RCA Configure-Ack 메시지 수신.
*RCN Configure-Nak 나 Configure-Reject 메시지 수신
*RCX RCR+,RCR-,RCA,RCN중 한 이벤트
*RTR Terminate-Request 메시지 수신
+-----------+
| 9 |
| Opened |
+-----------+
RCR+↗ ↖RCA
+-----------+ +-----------+
| 7 | | 8 |
| Ack-Rcvd | | Ack-Sent |
+-----------+ +-----------+
RCA ↖ ↗RCR+
+-----------+
| 6 |
| Req-Sent |
+-----------+
UP↗ ↖Open
+-----------+ +-----------+
| 1 | | 2 |
| Starting | | Closed |
+-----------+ +-----------+
Open↖ ↗Up
+-----------+
| 0 |
| Initial |
+-----------+
그림 3.4 레이어 성립 개략도
*RTA Terminate-Ack메시지 수신
*RUC 메시지에서 알수 없는 Code수신
*RXJ+ Code-Reject메시지 수신, 이때 code number은 비활성화 되어 질 수 있다.
(RFC 1661상태에서는 이 이벤트는 NCP들의 종료에 대한 허용에서 Protocol-Reject를
사용하기 위한 이벤트로도 쓰인다....역략)
*RXJ- Code-Reject를 수신/코드 번호를 disable하지 못하는 곳으로 예를들어, 코드가 01~04
까지 인경우.(RFC 1661 상태에서는 Protocol-Reject에도 사용되어 진다. RXJ+과 같은
이유라고 보기는 업렵지만, 종료는 NCP에 Protocol-Reject로 영향을 주게 된다.)
*RER Echo-Request를 수신.(RFC 1661에서는 Echo-Reply와 Discard-Request도 같이
분류한다.)
*RXR Echo-Reply 이나 Request message를 수신.
*SCR 새 Configure-Request 메시지를 보낸다.
*SCA 마지막으로 수신한 Cofigure-Request에 대하여 Configure-Ack를 보낸다.
*SCN Configure-Nak 나 Configure-Reject를 보낸다.
*STR Terminate-Request 메시지를 보낸다.
*STA Terminate-Ack 메시지를 보낸다.
*SCJ Code-Reject 메시지를 보낸다.
*SER Echo-Reply 메시지를 보낸다.
*tls 현재 레이어는 이미 시작되었다. 하위 레이어는 Open이벤트를 받을 것이다.
*tlf 현재 레이어는 종료되었다. 하위 레이어는 Close이벤트를 받을 것이다.
*tfu 현재 레이어는 UP상태이며 다음 상위레이어는 UP이벤트를 받을 것이다.
*tld 현재 레이어는 down이며, 다음 상위 레이어는 Down이벤트를 받을 것이다.
*irc restart-count를 초기화 한다.카운터는 최대 재전송으로, 타이머는 기본값으로 설정
*zrc restart-count를 0으로 초기화.이는 Opened상태에서 Terminate-Request가 수신되어
질때 사용된다.
+-----------+
| 9 |
Down----------------| Opened |-----------------------Close
| +-----------+ |
| ↓ RTR,RXJ- |
| +-----------+ |
| | 5 | ↓
| Down | Stopping | Close +-----------+
| <------ +-----------+ -------> | 4 |
| ↓RTA | Closing |
| +-----------+ +-----------+
| | 3 | |
| | Stopped | |
| +-----------+ |RTA
↓ ↙ Down Close↘ ↓
+-----------+ +-----------+
| 1 | | 2 |
| Starting | | Closed |
+-----------+ +-----------+
Close↘ ↙ Down
+-----------+
| 0 |
| Initial |
+-----------+
그림 3.5 레이어 종료 개략도