Course Outline
- synchronization (동기화)
- PDU handling / flow control
Synchronization
entity간 일관된 protocol operation을 위해 서로의 state를 맞누느 event 동작이 필요함
- connection setup / release 에서 주로 사용된다.
- 신호를 보내고 받을 준비가 서로 되어야 소통이 가능하다.
peer entity 간 connection
- 데이터를 보내기 전 connection이 맺어졌는지 여부 확인
- handshaking 방식을 통해 이루어짐
hanshaking
- 서로 합의하는 과정처럼 message를 주고 받음
- 2-way, 3-way
2-way handshaking
TX에서 (service primitive을 이용해서) CR를 보내면 RX에서 CC (connection confirm)을 줌으로서 동기화가 이루어짐
initiator entity (TX)
- request PDU 전송
- 관련 파라미터를 모두 담아서 한버에 responder에게 전달
- 전송률, 지연, 처리량, 와이파이 or LTE 등 채널 , PDU크기 정보 등
responder entity (RX)
- confirm PDU 전송
- confirm PDU 전송 직후 connection이 맺어졌다고 가정하고 받을 준비를 한다.
- confirm PDU이 loss가 발생해도 마찬가지로 connection이 맺어졌다고 가정
unidirectional(한방향) 형태의 전송을 2-way handshake로 충분하나, bidirectional 형태는 2-way 로하면 문제 발생
- unidirectional: TX에서 req PDU보냈고 RX에서도 confirm PDU보냈으므로 TX에서 data를 보내고 RX에서 받을수 있다
- bidirectional: Rx에서 confirm PDU가 loss났는데 data를 바로 보내면 TX는 데이터 전송만 할 수 있고 데이터를 받을 준비가 안된 상태이므로 RX에서 보내는 data가 자신에게 보낸 데이터인지 모른다.
- confirm PDU가 TX측으로 제대로 받아지지 않은 상태에서 initiator쪽에서 확인을 해주지 않으면 responder쪽에서는 confirm PDU가 제대로 받아졌는지 아닌지 알 수가 없다.
3-way handshake
- 주고 받고 또 주고
- request / setup / complete
- initiator (TX)가 confirmation 수신에 대해 responder에게 confirm을 또 해줌 (complete) → 2-way에서 confirm PDU가 loss가 일어나도 connection이 됐다고 했지만 3-way에서는 그게 안된다.
- responder는 complete을 수신한 뒤에 connection이 맺어진 것으로 간주
- complete에 loss가 일어나도 responder는 connection이 맺어진 상태로 가정할 수 있음
- 이전에 request는 받았고, 그에 대한 응답으로 confrim을 보냈다 (따라서 initiator의 상태는 확인되었다)
- initiator에게서 complete를 못받아도 후속 data PDU을 수신하면 complete을 수신한 것으로 간주할 수 있음.
Connection Management
connection-oriented protocol(TCP)에서 connection을 설정 / 관리 / 해제를 하기 위한 동작
- Connection establishment / data transfer / connection release 세 가지 동작
Connection Establishment (설정)
- establish connection: entity간 connection 연결 수용 / 거부 상태를 맞추는 과정, 여기서 협의가 이루어질 수 있다.
- hanshake 과정을 통해 동기화
- negotiate the quality of service (QoS): 전송에 대한 품질 협의 → throughput, delay, error / loss rate 이런 것을 협의
- responder는 connection request에 대해 받아들일 수 없는상황이면 reject할 수도 있다.
- resource 부족으로 connection을 다루지 못할 경우
- request 메시지 내에 요청한 QoS가 받아들일 수 없을때 → reduce로 거절할 경우 responder가 역제안을 주고, initiator가 받을지 말지 판단
peer entity들 간 connection을 설정하는 방법
explicitly(명시적)
- 2-way 혹은 3-way handshake 로 연결설정을 한다.
- 메시지 교환(연결하자고 연락하는 메시지)을 마치고 서로 연결 상태로 전환
- connection setup / data transfer phase 두가지로 명확하게 나뉨
implicitly(암시적)
- connection establishment 시도 시작과 동시에 connection이 맺어졌다고 가정
- confirmation 메시지를 기다리지 않고 REQ 전송과 함께 data 전송
- connection establishment delay가 성능 저하를 일으키지 않음
- 현대 무선 중심의 데이터 교환 환경에서 packet손실의 가능성이 매우 높으므로 이런 connection을 미리 갖는 것이(request PDU등 을 통해 사전 정보를 받고 QoS의 진행 등) data transfer가 안정적으로 진행 될 수 있다. → 찾아보기
- loss 혹은 connection reject시 PDU 재전송이 필요함
Connection Maintenance
문제가 생기는 경우 Re-establishment할 수 있다 정도로만 알고 있어도 충분하다.
- Breakdown of a connection 상황 발생시
- 하위 layer에서 문제가 발생하면 상위 layer에게 이를 알림
- Re-establishment of connection을 수행한다
- 상위 layer에서 하위 connection에 문제가 발생한 경우 취할 수 있는 조치
- re-synchronization : broken (N-1) connection 에 대해 reestablishment를 함
- reassignment : 새로운 (N-1) connection에 대해 establishment함
Connection Release
- SAP간 Connection이 더이상 쓸모가 없어졌을 때 수행
- explicit release: 불필요한 상황으로 인해 정상적으로 종료하는 경우
- abrupt release: 비정상적으로 종료하는 경우
Explicit release는 entity간 서로 합의 하에 종료
- peer간 release 상태에 대한 synchronization
- release직전의 data 전달 동작
- Release 상태에 대한 synchronization은 peer 간 메시지 교환을 통해 가능 하지만 메시지 유실 상황을 대비해야 함
- 잘못하면 half-open connection problem 발생
Unidirectional connection에 대한 release를 하려면
- (a) TX entity 쪽에서 release 요청을 해야 함 → RX entity는 PDU 전송 상황을 모르므로 release를 요청하면 PDU 유실 여지가 있음
- (b) release 요청 PDU 역시 sequence number를 가져야 함 → Reordering이 필요한 상황에서 마지막 PDU가 유실될 여지가 있음
- (b) Release 절차는 2 way handshake 형태로 이루어져야 함 → release 요청 PDU의 유실 상황에 대한 대비 release 요청을 받고 release confirm을 보내줘야 release 여부를 알 수 있음.
Bidirectional connection에 대한 release를 하려면
- 기본적으로 unidirectional connection두개에 대해 각각 release를 하는 것과 같음 (=half close)
- 3-way handshake 절차를 활용하면 한번에 양방향에 대해 동시에 release 가능
- TX → RX : (DR) release request 전송
- RX → TX : DR 요청 받고 똑같이 (DR)release request 전송
- TX: DISC ind(discard indicator)를 다음 layer 에 전송 & (DC)release confirm 전송
- RX: DC 받고 DISC ind를 다음 layer에 전송
- 양방향 connection에 대해서 모두 다 release하는 것
- PDU loss에 대한 대비를 통해 synchronization 문제 해결을 할 필요가 있음
3-way handshake에서의 synchronization 문제
- 대부분 PDU Timer로 해결
msg2 loss : 양쪽 모두 expiry (RX측 DR 손실 시)
- TX는 DR을 보내고, RX로부터 응답이 time out 시 release 수행
- RX 또한 DR을 보냈는데, TX로부터 confirm이 오지 않아 time out시 release 수행
- DR이 손실되었으므로 TX는 모른다
- TX, RX 모두 time expiry
msg3 loss : 수신 쪽만 expiry (TX측 DC 손실 시)
- TX는 release도 냈고, confirm도 받았으므로 release 수행
- RX는 DR 응답을 보내고, confirm에 대한 time out 시 release 수행
- RX만 timer expiry
msg1 loss : activity를 감시하는 별도 방식 필요
- TX : PDU Timer expiry
- RX : activity timer expiry
- TX는 DR을 보내고 난 후 time out 시 release 수행
- RX는 activity timer를 가지고 판단하게 된다. RX는 TX로부터 activity time out 시 TX가 동작하지 않는다 판단하고 release 수행
- activity timer: 실제로 TX가 동작하고 있는지 모니터링하는 타이머
- RX는 activity timer expiry를 사용
Abrupt connection release : immediate break-up
- 비정상적인 상황에서 곧바로 connection 해제
- data transfer loss가 필연적으로 발생할 수 밖에 없음
- exceptional case
- irreversible transmission error (되돌릴 수 없는 전송에러)
- security issue (데이터 보내는 도중 누가 듣고 있는 거 같다면 끊기)
- Reuse of connection reference 문제에 대한 방지
- freezing of connection reference : 일정 시간동안 해당 연결을 사용하지 않음
PDU Adjustment
- N -> N-1 layer mapping 형태는 크게 세가지가 존재
- one-to-one
- Multiplexing : 상위 layer의 여러 SAP을 모아서 처리
- Splitting : 하위 layer의 여러 SAP으로 분배
- SDU에 대한 처리도 구조에 맞게 이루어짐
Multiplexing 시 필요한 protocol functions
- Scheduling : N layer로부터 동시에 PDU 수신 시 (N-1) layer 로 우선 보낼 PDU 선택
- Flow control : (N-1) connection capacity 에 대한 regulation (개수 제한)
- Assignment : 수신한 (N-1) PDU를 N layer에 적절히 올림
Splitting 시 필요한 protocol functions
- Scheduling : 어느 (N-1) layer의 SAP으로 보낼지 결정
- aggregation : 수신 측에서 (N-1) connection들로부터 N PDU 생성
SDU에 대한 길이 조정
- maximum transfer unit (MTU)에 따라 윗단의 SDU size를 조정해야 하는 경우
- SDU를 자르거나 합쳐서 PDU를 만듬
- fragmentation : SDU가 너무 크면 잘라서 여러 PDU 생성
- Segmentation : SDU를 자르고 sequence를 매김, fragmentation와 거의 동일한 의미로 사용
- reassembling : reorder하고 합침
- overhead(쪼갤때마다 header 정보가 계속 붙어서)가 증가하긴 하나, error control, resynchronization 등 관점에서도 잘게 쪼게는게 유리할 수 있음
- concatenation : 작은 SDU를 하나로 합쳐서 보냄
- Chaining : 여러 SDU를 하나의 PDU로 합침 (합친 정보를header에 포함)
- separating : 다시 분리
Sequence Number
- Sequence number : connection management, PDU adjustment를 하는 대부분의 프로토콜은 번호 붙이기를 함
- PDU header에 붙임
- connection 상에서 전달되는 PDU의 전송상태 확인(synchronization)
- reordering / duplication 상황에서 number사용됨
- fragmentation / concatenation 상황에서 number사용됨
Sequence number를 관리하는데 있어서 두가지 고려 사항
- 서로 다른 PDU에 동일한 sequence 부여는 피해야 함
- freezing connection reference후 sequence reset
- forbidden zone 정의 → 이 정의로 같은 number부여를 피한다.
- sequence number overflow
- 최대값이 충분히 커야 함 (sequence number max)
- wrap around (max까지 도달하면 다시 0으로..)
Flow Control
- 송수신 entity 사이에 교환되는 PDU 개수 조정 (양조절), 아래 두가지를 고려해서 flow control한다.
- receiver entity에서의 processing overload (처리과부화)
- channel의 용량
window-based flow control(window sliding) : “window” (PDU range)내에서만 전송
- first transmission에 대해서 PDU range내에서 제한적으로 전송
- retransmission은 제한 없이 함
start/stop procedure
- 수신 측에서 stop signal을 보내서 제어
- 잦은 stop signal로 인해 discontinuous, bursty data flow 발생
- 예전 방식
credit procedure
- 수신 측에서 credit을 주고, sender는 허용된 credit (보통 sequencenumber 범위)에 따라 전송 → 수신이 송신한테 몇개가지 가능하다고 알려준다.
- 송신 측은 허용된 범위의 PDU를 보내고 나서 credit을 새로 받을때까지 기다림
- 요즘 protocol에 쓰임
Sliding window protocol
- 가장 보편적인 credit procedure
- 수신측이 제공한 credit 정보는 곧 window를 sliding해주는 양
Rate-based flow control
- rate를 미리 지정 → 한번에 보낼 수 있는 양을 미리 지정, 미리 양쪽에서 지정
- end-to-end 제한 뿐 아니라 network load 도 고려하는 흐름 제어
- network의 overload 상황을 방지할 수 있음
- 유선에서 사용한다.
- 송신 측에서 전송률에 대한 제한(얼마나 뭉쳐서 보낼 거냐를 약속)을 두고 전송
- 허용된 burst (특정 시간동안 보내는data) size를 제어
'CS > 컴퓨터네트워크' 카테고리의 다른 글
| 7. Layer 3: Internet Protocol (0) | 2023.04.15 |
|---|---|
| Layer 1 & 2 (0) | 2023.04.12 |
| Protocol Functions (0) | 2023.04.10 |
| Protocol Stack (1) | 2023.04.01 |
| Communications Networks and the Internet (0) | 2023.03.31 |
