protocol function 2

protocol function 은 여러 프로토콜에서 사용하는 특정 procedure/ mechanism 이다

Synchronization

• entity간 지속적인 protocol operation을 위해 서로의 state(FSM - 기기의 상태)를 맞추는 event 동작이 필요함
• 다시 말해면 connection을 연결하기 위해서 Tx 는 송신 준비를 Rx는 수신 준비를 하는거암
• 주로 connection setup 이나 release에서 활용함
• 주로 pyhsical layer에서 일어나고 연결이 확정되지 않는다면 pdu전송이 불가능하다.
• data를 보내기 전에 entity간의 connection이 맺어졌는지 여부를 확인하고 connection이 연결되지 않으면 데이터가 전송되지 않는다.

  • handshaking 서로 합의하는 과정처럼 connent request(message)를 주고 받는데

    2-way handshaking - 한번왔다 가는 것이 특징이다 과정은 다음과 같다

  • Tx 에서 connect request를 보내고

  • Rx에서 connect indication이 발생해서 요청이 왔음을 Rx가 인지하고

  • Rx 에서 connect response를 Tx에 보낸다

  • Tx 에서 connect confirm이 일어난다

  • initiator entity: request PDU를 전송한다 이때 pdu에 관련 parameter를 모두 담아서 한번에 responder에게 전달한다

  • responder entity: confirm PDU를 전송하는데 전송 직후 connection이 맺어졌다고 가정한다 이 말은 다시 말해서 confirm pdu가 Tx측에 도달하지 않아도 연결이 맺어졌다고 가정하는 것이다. 두번만왔다갔다고 하니까 Rx는 확인할 방법이 없는거임

  • unidirectonal 형대의 전송은 2-way handshake 형태로 충분하나 bidirectional 형태의 전송은 2-way handshaking형태로는 문제가 발생한다. 그 이유는 2 way를 사용하면 confirm pdu가 손실이 일어난 경우에는 Rx측에서는 알수가 없기 때문에 서로 확인이 불가능해서 문제가 발생하는거다 다시 말해 서로 initial 쪽에서는 끝까지 연결이 안됐는데 reponder쪽에서는 연결이 되어있다고 생각할 수도 있는것이다. 이렇게 문제가 발생하면 아예 연결 자체가 성립이 안되었기 때문에 Timer로는 해결이 불가능한 상황이 만들어져서 재전송을 해도 여전히 상대방은 discard한다.

    3-way handshaking(주고 또 받고)

  • request/ setup/ complete 세 가지 과정을 포함하는 과정이다.
    - initior 가 reponder의 confirm pdu에 대해서 다시 complete를 보내서 확인을 한번더 한다
    - 2-way와는 다르게 reponder는 complete를 수신해야 연결이 된것으로 가정한다.
    - 하지만 reponder는 complete에 loss 가 일어나도 reponder는 connection이 맺어진 상태로 가정할 수 있음

        그 이유는 이전에 request는 받았으므로 connection을 맺고자 하는 initiator의 상태 확인할 수 있다는 것이다 이후 reponder에서 보낸 후속 pdu를 수신하면 complete을 수신한 것으로 간주할 수 있다.
        

    connection management

  • connectino management은 connection-oriengted protocol 에서 connection을 설정/관리/해제를 하기 위한 동작이다

  • connection management는 3가지로 구정되는데

    1. connection establishment - 연결을 설립하는 과정
    2. data transfer - 데이터를 전송하는 과정
    3. connection release - 연결을 끊는 과정

  • connection establichment
    - establish connection : entity 간connection 연결 수용/거부 상태를 맞추는 과정이다. 이는 위에서 언급했던 hand shake과정을 통해서 일어난다
    - 또한 Negotiate the quality of service(QoS): 전송 품질에 대한 협의 또한 connection establish에서 일어난다. QoS는 throughput, delay error/loss rate에 의해서 정해진다.
    - initiator 가 연결을 생성하기 위해서 connection을 보내면 이에 대해서 거절할 수도 있는데 이유는 다음과 같다
    - resorce 부족으로 connection을 다루지 못하기 때문에
    - requset 메세지 내에 요청한 QoS을 다루지 못할때
    - 위의 경우에 responder가 역제안을 보낼 수 있고 이를 reduce라고 한다
    - 이 reduce에 대해서 intiator가 받을지 말지 판단을 하고 연결을 성립한다.

        ### peer entity간의 연결을 설정하는 방법
        
        - peer entity간의 connection을 설정하는 방법에는 크게 2가지로 나눌 수 있는데 하나는
        1. explicity(명시적 방법) : 메세지 교환을 마치고 서로 연결상태로 전환하는 방법이다. 이때 사용하는 방법이 위에서 언급했던 2-way, 3-way방법이다. 이는 명확하게 conneciton setup/ data transfer phase로 나뉜다.
        2. implicitly(암시적인 방법) :connection establishment 시도 시작과 동시에 connection이 맺어졌다고 가정하는 방법이다.
            1. confirmation 메세지를 기다리지 않고 REQ(요청메세지)전송과 함께 data 전송한다
            2. connection establish delay(연결성립지연)이 통신 지연을 일으키지 않는다
            3. 근데 이때 requset massage의 손실이 일어나는 경우에는 rrequset 메세지를 보냄과 동시에 보냈던 pdu들에 대해서 재전송이 필요한 상황이 발생한다.
            
        
        ### connection maintenance
        
        - breakdown of a connection(연결 끊김) - 연결이 끊긴경우에 하위 레이어에 문제가 발생하면 위에 레이어에 이를 알린다.
        - re-establishment of connection - 연결이 끊긴 경우에 이를 다시 연결하는 과정
            - 상위 layer 에서 하위 connection에 문제가 발생한 경우 취할 수 있는 조치는 두가지로 나뉘는데 하나는
                - re-synchronization: 이고 이는 끊긴 연 n-1 과의 연결에 대해서 다시 설립하는 것이다 위에서 설명했던 Qos 암시적, 등등의 방법은 끊기기전과 동일하게 유지하는 것이다
                - reassigment: 새로운(N-1) connecition에 대해 establishment하는것으로 연결을 다른 조건으로 다시생성하는 것이다
        
        ### connectton release
        
        - SAP간 connection이 더이상 쓸모가없어졌을 때 연결을 끊기 위해서 수행하는 과정이다.
            - explicit release - 불필요한 상황으로 인해서 정상적으로 종료하는 경우이다 이는 ENTITY간의 합의 하게 종료되는 것으로 peer간 release 상태에 대한 synchronization이 일어나고 relsease 직전에 data 전달 동작이 일어난다.
            
            - abrupt release - 비정상적으로 종료하는 경우
            
            ### connection release
            
            - release 생태에 대한 동기화는 peer간의 메세지 교환을 통해서 일어난다 다만 DataRelease에 유실 상황에 대해서 대비해야한다
            - peer 간 메세지 교환을 통한 release 상태에 대한 syncronization 종료를 위한 요청을 보냈고 응답으로 ACK를 보냈지만 반복적으로 ACK유실이 발생했고 time out 으로인해서 재 송신을 반복하다가 일정 횟수 이후에는 강제로 연결이 종료된다.
            - 잘목하면 half open connectio problem이 발생하기 때문이다 이는 한쪽만 연결되어있는 상황이다.
            
        - unidirecitonal connection에 대한 release(단방향통신에 대한 연결해제ㅐ)
            - 반드시 TX쪽에서만 release를 요청해야한다 그 이유는 Rx쪽에서는 PDU전송 상황에 대해서 알 수 없기 때문에 pdu 유실에 대한 여지가 있기 때문이다.
            - release 요청 pdu역기 sequence number를 가져야 한다 그 이유는 reordering즉 다시 새로운 정렬이 필요한 상황에서 마지막 pdu가 유실될 가능성이 있기 때문이다.다르게 말하면 release message가 마지막 pdu보다 먼저 도착할 가능성이 있기때문에 releasw message에서 pdu이후의 메세지임을 알려주어야 한다.
            - release 절차는 2-way handshake의 형태로 이루어져야 한다 그 이유 confirmation으로 release를 확인을 통해서 half open을 막기 위함이다.
        - bidrectional connection 에 대한 release
            - bidrectional connection 에 대한 release를 하려면 기본적으로 unidirectional connection 두개에 각각 release를 하는 것과 같다(half close)
            - 한쪽의 연결에 대해서 2-way를 실행해서 하나를 끊는데 중간에 다르쪽에서 pdu의 전송이 가능하다.
            - 3-way handshake를 이용하면 한번에 양항향에 대해서 동시에 release가 가능하지만 pdu loss 에 대한 대비를 통해 동기화 문제를 해결할 필요가 있다bidrectional
            - 
            
            ![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/8eff59b1-15f0-4a8b-b9c0-faf81fbcdacc/Untitled.png)
            

    bidrectional 연결에 대해서 relesase를 수행하면 messageloss 에 대해서 대비를 해야하는데 오류으 유형은 다음과 같다

    먼저 절차를 설명하자면

  1. Tx 에서 Rx에게 DR전송한다 -msg1

  2. Rx에서 Tx에거 Dr을 전송한다 - msg2

  3. Tx 에서 Rx에게 Dr을 전송하고 동시에 다음 레이어 에거 DISCind(disconnection indication)을 보낸다 - msg 3

  4. Rx - Tx에서 보낸 Dr 에 대해서 confirmation을 하고 release한ㄷ

     이 때

  • msg2번에서 이상이 발생한경우에는 Tx 는 msg1 에 대한 응답을 기다리다가 time expire 그리고 Rx도 응답을 보냈으니까 msg 2에 대한 confirm을 기다리다가 time expire 결론은 다 expire된다.

  • msg 3 에서 이상이 발생하는 경우네는 Rx는 msg2에 대한 응답을 기다리가다 expire가 된다.

  • mag1 에서 이상이 발생하는 경우에는 Tx 는 msg1에 대한 응답을 기다리다가 timeout 해서 release되고 Rx는 Activity timer에 의해서 Tx의 비활성을 알아차리고 release한다.

    비정상적인 종료

  • abrupt connection release: immediate break up
    - 비정성적인 상황에서 곧바로 연결을 해제한다
    - data transfer loss 가 필연젹으로 발생할 수 밖에 없다
    - 예외적인 경우
    - 재귀불가능한 에러가 발생한경우 이거나 보안의문제가 발생한경우
    - reuse of connenction reference 문제에 대한 방지
    - freezing of connection reference - 그냥 쉽게 말해서 문제가 발생한 연결은 당분간 사용하지 않는다는 것이다. 그 이유는 같은오류가 발생하니까

    pdu adjustment

  • n - > n-1 layer maping 형태는 크게 3가지로 존재하는데

    

    • multiplexing시 필요한 protocol funciton
      • scheduling n layer로 부터 동기에 pdu 수신 시 n-1 layer 로 우선 보낼 pdu선택하는 기능이 필요하다
      • flow control:(n-1) connection capacity에 대한 regulation
      • assignment : 수신한 (n-1) pdu를 n layer에 적절히 올림
    • splitting 시 필요한 protocol function
      • scheduling - (n-1) layer 의 sap으로 보낼 지 결정
      • aggregation - 수신 측에서 n-1 connection 들로부터 n pdu 생성
    • SDU에 대한 길이조정
      • MTU(maxium transfer unit 에 따랏 위단의 SDU 의 size를 조정해야하는경우 SDU를 자르거나 합쳐서 PDU를 생성한다.
    • fragmentation : SDU 를 자르고 sequence를 매김
      • reassembling reoder 하고 합친다.
      • pdu를 자르면 overhead( 즉 해드파일도 여러개 생성되서 않좋긴한데 재 동기화 관점에서 잘게 쪼개는 것이 유리하다.
    • concatenation: 작은 SDU를 하나로 합쳐서 보낸다
      • chaining: 여러 SDU를 하나의 PDU로 합친다(합친 정보를 header)에 포함
      • seperating:다시 분리
    • sequence number: connenction management, pdu adjustment 를 하는 대부분의 프로토콜은 번호를 붙이기로함
      • pdu의 헤더에 붙인다
      • connection 상에서 전달되는 pdu의 전송상태확인
      • reordering/ duplication
      • fragmentation / concentenation 전후로 sequence number가 존재한다.

  • sequence number 를 관리 하는데 있어서 주의사항 서로다른 pdu에 동일한 sequence 부여는 피해야한다.

    • freeezing connection reference 후 sequence reset - 당분간 사용하지 않는 연결을 설정하면 sequence number도 다시 리셋해한다
      • frobidden zone 정의 한번사용한 sequence는 당분간은 다시 사용하지 말아야한다
    • swquence nimber overflow
      • overflow를 막기 위해서 최댓값이 충분히 커야하고
      • 1- 100까지 중에 모두 사용했다면 다시 1로 돌아간다.

  • flow control 송수신 entity사이에 교환되는 pdu 개수 조정 transport layer에서 가장 많이 일어난다.

    • 송수신 엔티티 사이에서 교환되는 pdu의 개수를 조정한다

  • 만일 Rx와 Tx의 처리능력이 떨어지는 무작정 보내면 안되니까 이를 보완하기 위해서 processing overload 가 일어나지 않도록 조절해서 보내야한다 또한

    • reciver entity 에서의 processing overload가 밸생하지 않게하기 위해서 와 channel 용량ㅇ르 고려해서 전송해야한다

  • window baseed flow control

    • window(허용된 pdu range) 전송을 하게 되는 것ㄷ., retransmission(제전송) 은 제한없이한다.
      • 첫번재 전송에 한해서만 window의 제한 용량으로 전송을 해야한다.

  • stop and stop procedure 거의 사용하지 않는다

    • 수신측에서 stop signal을 보내서 제어한다
    • 잦은 stop signal로 인해 discountinuous, brusty data flow가 발생한다(brusty data 데이터가 갑자기 집중적으로 소규모로 발송되는 것)
    • ㄴ

  • credit procedure

    • Rx에서 credit을 주고 , Tx는 허용된 cerdit( 보통 sequence 범위)에 따라 전송한다는 Tx 여청한 credit이 올때 가지 기다린다
    • 즉 RX에서 요청한만 양만큼 TX에서 보내는 것이다.
    • sliding window protocol

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

        초기에는 자기자신이 8개의 원도우를 가지고 있다고 알린다 그 후에 데이터를 전송학 수신측에서 cerdit에서 몇개의 sequence까지 보내라는 credit을 보내고 그 크리딧에 따라서 양을 조절해서 보내게된다.

        

        pdu sequence 음 슬라이딩 윈도우 프로토콜에서 가장 처음 윈도우의 사이만큼의 pdu를 전송한다 그리고 전송은 했지만 ack를 받지 안은 pdu들이 윈도우에 포함되게 되고 윈도우에 있는 pdu를 받았다는 ack가 들어오면 그 ack 시퀀스 가 윈도우 밖으로 나갈 수 있게 윈도우를 뒤로 밀고 아직 전송되지 않은 pdu들이 윈도우에 들어오게 된다. 초기에 한번에 윈도우의 수 많큼 전송을 한다는 점에서 의미기가 있는거다

        rate based flow control

        end to end 제한 뿐만아니라 network load도 고려하는 흐름제어이다

        net work 의 over load 상황을 방지할 수 있다

        송신측에서 전송률에 대한 제한을 두고 전송하는 것이다