[네트워크] Protocol Function 2

 

Synchronizaion

entity 간 연속적인 protocol operation(연산)을 위해 서로의 state를 맞추는 event동작이 필요하다

즉, 데이터를 서로 주고받기 전 연결을 확실히 맺고 또는 연결을 확실히 끊었다는 것을 보장하는 것이다.

 

 

호 연결

: data를 보내기 전에 peer entity 간 connection이 맺어졌는지 여부를 확인하는 것

 

호 연결을 하기 위해 handshaking이란 것을 한다. 

handshaking이란 서로 합의하는 과정 처럼 message를 주고 받으면서 연결 여부를 확인 하는 것이다.

handshaking에는 2-way handshaking 과 3-way handshaking이 있다.

 

1) 2-way handshaking

       

 

  ➡️ 송신측과 수신측 한번씩 메세지를 전송한다

  initiator entity(송신측) : request PDU을 수신측에게 전송한다. 이때 관련 파라미터를 모두 담아서 전달한다.

  responder entity(수신측) : confirm PDU를 송신측에게 전송한다. 전송한 직후 수신측은 연결이 맺어졌다고 가정한다. 즉, confirm PDU가 중간에 가다가 손실이 되었어도!! 연결이 맺어졌다고 가정하는 것이다.

 

2-way handshake에는 한가지 문제가 있다.

만약 한쪽방향에서만 데이터를 전송하는 unidirectional 형태 전송인 경우는 괜찮지만

양쪽방향으로 데이터를 전송하는 bidirectional 형태 전송은 2-way handshake로는 문제가 발생할 수 있다.

다음과 같은 경우이다.

➡️ 만약 confirm PDU가 중간에 loss된 상황이면 송신자 측은 연결이 아직 맺어진 상태가 아니기 때문에 수신측이 이후에 보내는 data는 받아들이지 않고 discard를 한다. 

➡️ 수신측은 confirm PDU를 보내고 연결이 맺어졌다고 가정하기 때문에 data를 보내지만 송신측에게 계속 discard를 당한다.

 

따라서 bidirectional 형태 전송은 3-way handshake 방식을 사용해야한다.

 

2) 3-way handshaking

 

➡️ 송신측에서 수신측에서 보낸 confirmation 수신에 대해 confirm을 또 해주는 것이다(complete)

 

수신측은 송신측이 보낸 complete를 받아야 연결이 맺어진 것이라고 간주한다.

여기서  complete loss가 발생해도 수신측은 연결이 맺어진 것이라고 가정할 수 있다!!

왜냐하면 이전에 송신측에서 request를 받았기 때문에 송신측이 연결을 맺고자 하는 것을 알 수 있고, 후속 data PDU를 받으면 수신측이 complete를 보냈다는 것(보냈지만 loss가 나서 못 받았었구나)으로 간주 할 수 있기 때문이다.

 

---

Connection Management

: connection-oriented protocol에서 connection을 설정 / 관리 / 해제 하기 위한 동작

크게 3가지로 나누어 볼 수 있다.

connection establishment(연결을 설립)  /   data transfer(데이터를 전송)  /  connection release(연결을 끊음)

 

1) Connection establishment 

     - Establish connection: entity 간에 connect 연결을 수용할 지 거부할 지의 상태를 handshake 과정을 통해 syschronizaion 함

 

     - QoS(Negotiate the quality of service): 전송에 대한 품질을 협의하는 것이다.

        품질: throughput(처리율), delay(지연), error/loss rate(에러율, 손실률)

 

     - 송신측이 connection request를 보내면 수신측은 accept할 수도 있지만 reject, reduce도 가능하다

         ✔️ reject 하는 이유:  resource 부족(예를 들면 다른 entity와 통신하느라 바쁘면), 송신측이 요청한 QoS를 받아들일 수 없을 때

         ✔️ reduce의 경우: 수신측이 역제안을 주고 송신측이 받아들일지 말지 판단한다

 

    - Peer entity 간 connection을 하는 방법(2)

 

       (1) explicitly : 메세지 교환을 마치고 서로 연결 상태로 전환 한 후에 데이터를 주고 받는 방법

           

        ▶️ connection setup 과 data trasger phase 두 가지로 명확하게 나뉜다

        ▶️ 2-way 혹은 3-way handshake를 활용

 

    

     (2) implicitly : 연결을 맺으려는 시도 시작과 동시에 connection이 맺어졌다고 가정

 

        ➡️ connection 요청을 보낸 후 confirmation 메세지를 기다리지 않고 request와 date를 함께 전송

 

        - 장점

        ➡️ confirmation 메세지를 기다리지 않기 때문에 connection establishment delay가 성능 저하를 일으키지 않음

        - 단점

        ➡️ loss 혹은 connection reject 시에는 PDU 재전송이 필요함

 

 

2) Connection Maintenance

 - Breakdown of connection (연결에 문제가 발생 시)

   하위 layer에서 문제가 발생하면 상위 layer에게 이를 알린다.  

    그러면  다시 connection을 맺기 위해 Re-establishment를 함

  

     ✔️Re-establishment of connection

     (1) re-synchronizaion : broken(N-1) connection에 대해 re-establishment

     (2) reassignment : 새로운 (N-1) connection에 대해 establishment

 

 

 

3) Connection Release

SAP 간 Connection이 더이상 쓸모가 없어졌을 때 Connection Release를 함

두 가지 경우로 release할 수가 있는데, 

첫번째는 정상종료하는 경우 explicit release

두번째는 비정상적 종료를 하는 경우 abrupt release 

 

   (1) Explicit release 

    -   Release 상태에 대한 synchronization 은 peer간 메세지 교환을 통해 가능

         하지만 메세지 유실이 발생하면 잘못하면 half-open connection problem이 발생한다

         half-open connection 이란 한쪽은 release가 되었는데 한쪽은 release를 안한 상태를 말한다

         다음 그림과 같이 유실 상황이 발생할 수 있음

       

 

   ➡️ c) 같은 상황이 half-open connection 이다. 송신측은 일정 시간 이상 ACK 를 받지 못했기 때문에 수신측이 deadlock를 할까봐 release를 하지 못하고 다시 요청을 보내지만, 수신측에서는 release요청을 받고 ack를 받았기 때문에 release를 함

 

 

        [ Unidirectional connection release ]

   - Tx entity 쪽에서만 release 요청이 가능하다

     만약 Rx쪽에서 release 요청이 가능하면 Tx가 보낸 PDU의 전송상황을 모르기 때문에 PDU유실이 발생할 수 있음

   

 

 

    - Release 요청 PDU 역시 sequence number을 가져야 한다

      마지막 PDU가 유실 될 수도 있기 때문에 Tx가 보낸 것들은 sequence number를 가져야 함

   

   -  Release 절차는 2-way handshake 형태로 이루어져야 한다.

      release 요청 PDU가 유실 될 수도 있기 때문이다.

      

     다음의 그림이 Unidirection connection release를 할 때의 올바른 형태이다

     

sequence number도 가지고, 2-way handshake를 한 형태

  

  [ Bidirectional connection release ]

  - 기본적으로 Unidirectional connection 두개를 각각 release를 하는 것과 같다

 ➡️ E1 에서 release를 요청하고 confirm을 받으면 E1은 데이터를 보내지 않고 받는 상태가 된다(half close)

 ➡️ E2 에서는 E1이 release 했어도 그 후에 데이터를 전송할 수 있고 나중에 release를 요청 할 수 있다

 

 

 - 3-way handshake를 하면 양방향에 대해 동시에 release를 할 수 있다

➡️ E1에서는 release 요청을 하고  E2에서 보낸 release 요청을 받으면 disconnection를 한다

➡️ E2에서는 release 요쳥을 하고 E1에서 보낸 confirm을 받으면 그때 disconnection을 한다

 

 

  ✔️ 3-way handshake 에서의 synchronization 문제 

        대부분 PDU Timer로 해결한다!!!

 

      (1)  msg2 loss: 양쪽 모두 expiry

              ➡️ E1 에서 release요청을 하고 타이머를 시작한 다음 E2에서 타이머가 끝날 때까지 release가 오지 않으면 연결을 끊는다

              ➡️ E2 에서 release요청을 하고 타이머를 시작한 다음 E2에선 타이머가 끝날 때까지 comfirm이 오지 않으면 연결을 끊는다

 

   (2) msg3 loss: 수신쪽만 expiry 

   

              ➡️ E1에서는 release cofirm을 보내고 나서 연결을 끊는다

              ➡️ E2에서는 release 요청을 보내고 타이머를 시작한 다음, 일정시간동안 confirm 이 오지 않으면 연결을 끊는다

 

 

  (3) msg1 loss: actity를 감시하는 별도의 방식이 필요

   

            ➡️ E1에서는 release 요청을 보내고 타이머를 시작한 다음,  일정시간동안 E2에서 release 요청을 보내지 않으면 연결을 끊는다

            ➡️ E2에서는 Activity timer(항상 긴 시간) 동안 E1에서 아무런 데이터를 보내지 않으면 연결을 끊는다

 

 

 

2) abrupt release 

   비정상적인 상황에서 곧바로 connection을 해제 한다. 이때는 무조건 data transfer loss가 발생 할 수 밖에 없다.

   

  - Reuse of connection reference 문제 방지

    비정상적을 종료된 연결은 바로 연결을 시도하지 않도록 holding 해준다 -> freezing of connection reference(일정시간동안 연결 사용 X)

   

 

  - 예외적으로 abrupt release 되는 경우

     irreversible transmission error : 서로 약속이 맞지 않아서 연결을 끊어버림

     security issue

 

---