5. Protocol Function 3

PDU Adjustment

N → N - 1 Layer mapping 을 위한 PDU 크기 조정

3가지 방식
- one to one
- Multiplexing : 상위 layer의 여러 SAP을 모아서 처리
- Splitting : 하위 layer의 여러 SAP로 분배
SDU에 대한 처리 또한 구조에 맞게 이뤄진다

Multiplexing 시 필요한 protocol functions
Scheduling (n → n-1)
- 화장실은 한개, 줄은 여러줄일때 어느 줄부터 화장실로 보낼지
- N layer의 SAP에서 동시에 PDU를 수신시, N layer에서 어떤 SAP부터 N-1 layer로 내려보낼지 정하는 것
Assignment (n-1 → n)
- (N - 1) layer에서 N layer의 어떤 SAP에 먼저 올려 보낼지 정하는 것
flow control
- SAP을 한번에 보낼지, 2개씩 보내지 등을 정하는 것

Splitting 시 필요한 protocol functions
Scheduling
- 화장실은 여러개이고 줄은 하나일때, 어느 화장실로 보낼지 정하는 것
- N layer에서 N-1 layer의 어느 SAP으로 내려보낼지 정하는 것
Aggregation
- N - 1 Layer에서 N Layer에 PDU를 올릴 때 SAP을 몇개씩 모아서 PDU를 생성해서 올릴지 정하는 것

SDU에 대한 길이 조정
- Maximum Transfer Unit (MTU)에 따라 윗단의 SDU size를 조정해야 하는 경우
- SDU를 자르거나 합쳐서 PDU를 만든다

Fragmentation (잘라서 만드는 경우)

SDU가 너무 크면 잘라서 여러 PDU를 생성한다RX측 → Reassembling : 잘라서 만든 PDU를 RX 쪽에서 reorder하고 합친다

TX측 → Segmentation : SDU를 잘라서 sequence를 매긴다

잘게 쪼갠 여러 PDU를 생성할 때 PCI (protocol control information)이 붙으므로 overhead가 붙기는 하지만,
error control, resynchronization 등에서 오류가 난 특정 PDU만 새로 보낼수 있는 등 결과적으로 오버헤드는 줄어든다

Concatenation (합쳐서 만드는 경우)

작은 SDU를 하나로 합쳐서 PDU를 생성한다RX 측 → Seperating : 합친걸 다시 분리한다

TX 측 → Chaining : 여러 SDU를 하나의 PDU로 합친다 (합친 정보는 header에 포함)
PDU를 더 적게 생성하므로 overhead가 적어진다

Sequence Number

Connection Management, PDU Adjustment 를 하는 대부분의 프로토콜은 번호 붙이기를 한다

PDU header에 붙인다
- 위에서 내려온 SDU가 60byte일 때, 이를 10byte씩 잘라서 PDU를 만들어서 보낸다고 할때, 해당 PDU의 header에 1 ~ 6번을 부여
connection 상에서 전달되는 PDU의 전송상태 확인 (PDU header에 있는 번호를 보고 확인)
reordering / duplication
- PDU를 전송받을 때 순서가 달라져서 들어올 수 있는데, 이때 sequence number를 통해 순서대로 재정렬하거나 중복된 값을 처리할 수 있다
fragmentation / concatenation
- 받은 PDU들 중 번호 1 ~3번이 하나의 SDU였음을 header정보에 포함하고, 이를 받은 측에서 그 정보를 통해 reassembling을 할 수 있게 된다

주의사항

서로 다른 PDU에 동일한 sequence 부여는 피해야 한다
- freezing connection reference 후 sequence reset
- forbidden zone 정의
- 해당 수를 사용하고 일정 시간동안은 그 수를 사용하지 못하도록 설정 해야한다

시퀀스 넘버의 오버플로우 방지를 위해 최대값이 충분히 커야한다
- wrap around
- 너무 bit를 크게 잡으면 낭비이므로 mod를 통해 계속 커지는 게 아니라 0~설정값 까지 돌았으면 다시 0부터 시작하게 해야한다

Flow Control

송수신 Entity 사이에 교환되는 PDU 개수를 조정한다
- why? → unbalance한 link의 현상이 존재하므로 해줘야 한다.
만약 RX의 PDU 처리능력이 상대적으로 떨어지는데 TX가 무작정 보낼수 없다. 또한 유선의 10Gb로 보낼때와 무선의 2.4Gb로 보낼 때의 차이 등 적절한 상황에 맞게 PDU를 보내줘야 한다
- receiver entity에서의 processing overload
- channel의 용량

방식

window-based-flow control
- window(허용된 PDU range) 내에서만 전송을 하게 되는 것단, re-transmission(재전송)은 제한 없이 한다
- first transmission에 대해서는 PDU range 내에서 제한적으로 전송해야한다

start / stop procedure (거의 사용 X)
- 수신 측에서 stop signal을 보내서 제어한다
- 잦은 stop signal로 인해 discountinous, bursty data flow가 발생
+ (bursty : 데이터가 갑자기 집중적으로 한번씩 소규모로 발송)

credit procedure
- RX에서 credit을 주고, TX는 허용된 credit (보통 sequence number 범위)에 따라 전송한다TX는 요청한 credit 만큼의 PDU를 보내고 새로운 credit이 올 때까지 대기한다
- 즉, RX에서 요청한 양만큼만 TX에서 보내는 것

Sliding window protocol

가장 보편적인 credit procedure 방식으로 RX에서 제공한 credit 정보는 곧 TX측 window를 sliding 해주는 양이다

초기 RX는 TX에게 자신이 8개의 window를 가지고 있음을 알려준다

1. TX가 DT(0~2) 3개를 보내준다
2. RX가 DT(1)을 받고 2번을 받을 준비가 됐음을 ACK를 통해 알려준다
3. TX가 DT(3~4) 2개를 보내준다
4. RX는 DT(3)을 받고 4번을 받을 준비가 됐음을 알려준다
5. RX가 DT(4)를 받고 5번을 받을 준비가 됐음을 알려준다

Rate - based flow control

ent to end 제한 뿐만 아니라, network load 도 고려하는 흐름제어
network의 overload 상황을 방지할 수 있다
RX에서 Credit을 이용해 전송률에 제한을 두고 전송하며, 허용된 burst size를 제어한다
유선에 주로 사용하는 방식이다 (무선은 둘다 사용한다)

RX에서 주는 credit을 확인해서 TX에서 데이타를 보내게 된다. 이때 RX의 ACK에 creadit 정보가 포함되어있다

1. RX의 credit == 4
   TX에서 DT(0 ~ 3) 4개를 보낸다
2. RX의 credit == 0
   RX에서 DT(4)를 받을 준비가 됐다고 알린다, 이때 Credit도 재설정 후 보낸다
3. RX의 credit == 4
   TX에서 DT(4~7) 4개를 보낸다
4. RX의 credit == 0
   RX에서 DT(8)을 받을 준비가 됐다고 알린다, 이때 Credit도 재설정 후 보낸다

즉, TX에서는 RX에게서 받은 credit을 가지고 DT를 보내게 되고, credit이 다떨어지면 ACK를 통해 새로운 credit이 올때까지 대기하게 된다